у тебя есть база userside-12
ты хочешь протестировать обвновление до userside-13
тебе незачем создавать нового пользователя для этого
ты создаешь базу данных userside-13 на основе userside-12 с теми же владельцами. полная копия
далее копируешь сам ЮС, указываешь в нем новую БД userside-13 и обновляешься.
В результате у тебя есть старый ЮС с БД userside-12 и новый с userside-13
Ты можешь просто удалить старый и продолжить работать на новом, если обновление прошло удачно
Так что в этом алгоритме нет смысла в другом владельце

ну это и так описано в резервном копировании :)

еще раз повторять те же команды, но в контексте создания копии - смысла нет. это и так очевидно. инструкция ведь не для домохозяек все таки

она должна быть как можно короче :) это важно :)

У меня основная претензия к pg_restore, что он может перезаписать исходник и это не очевидно

очевидно, если знаешь, что такое дамп

Все остальное уже мои заморочки

Вообще это временная остановка на пути к 3.14, если с коммутацией вопрос решится

дело в том, что дамп нельзя расценивать как sql бекап

это немного разные вещи (на самом деле сильно разные)

дамп это как-бы бинарное состояние базы (не совсем, конечно, но можно так считать для простоты)

он всегда содержит полную информацию о базе данных и никак иначе

если когда ты делаешь бекап в sql - ты можешь указать, что именно туда помещать, то с дампом все наоборот - что именно извлекать ты указываешь при restore, а вот при создании дампа туда безусловно попадает всё

Ну вот я при ресторе указал базу а оно залило в исходную

ты указал create

🙈

ты скопипастил из инструкции и не прочитал что это за команда

там же русским по белому написано

ладно я плохо русский знаю. не мой родной язык. но ты то!