Смысл возникает в системах с более чем одним сервером SQL в моменты смены бранча, то есть регулярно. Если версия только одна - надо апгрейдить всю ферму единовременно (не пробовали? тот ещё спорт). А если в бранче актуальная и предыдущая, из предыдущего бранча - апгрейдить можно волной, и это гораздо-гораздо легче. Иными словами, если в p11 будут и postgresql16-1C-contrib и предыдущий, postgresql15-1C-contrib как в p10 - это будет счастье. А если только один postgresql16-1C-contrib - это проблема. И их зависимостей это тоже касается.
Не пойму в чем тут проблема. При наличии в системе более ранней мажорной версии, она более новой не замещается. И смысла еще одной сборки не вижу.
(Ответ для Alexei Takaseev на комментарий #1) > Не пойму в чем тут проблема. При наличии в системе более ранней мажорной > версии, она более новой не замещается. И смысла еще одной сборки не вижу. При обновлении с p10 до p11 пакеты выносятся и нет возможности перенести базу на новую версию.
Логично собрать сам сервер без расширений.
Или делать обновление через postgresql14-14.12-alt2 ?
(Ответ для Andrey Cherepanov на комментарий #2) > (Ответ для Alexei Takaseev на комментарий #1) > > Не пойму в чем тут проблема. При наличии в системе более ранней мажорной > > версии, она более новой не замещается. И смысла еще одной сборки не вижу. > > При обновлении с p10 до p11 пакеты выносятся и нет возможности перенести > базу на новую версию. Погодите. Можно более конкретно с логами. Потому как еще со времен Master 2.2 автоматом обновления мажорных версий не производится.
(Ответ для Alexei Takaseev на комментарий #5) > (Ответ для Andrey Cherepanov на комментарий #2) > > (Ответ для Alexei Takaseev на комментарий #1) > > > Не пойму в чем тут проблема. При наличии в системе более ранней мажорной > > > версии, она более новой не замещается. И смысла еще одной сборки не вижу. > > > > При обновлении с p10 до p11 пакеты выносятся и нет возможности перенести > > базу на новую версию. > > Погодите. Можно более конкретно с логами. Потому как еще со времен Master > 2.2 автоматом обновления мажорных версий не производится. Это понятно! Для перехода на новую мажорную версию должны быть бинарники старой, чтобы выгрузить дама базы и засосать его в новый (https://www.postgresql.org/docs/10/upgrading.html). Так? Вот старые бинарники и предлагается как contrib без расширений оставить в репозитории.
(Ответ для Andrey Cherepanov на комментарий #6) > (Ответ для Alexei Takaseev на комментарий #5) > > (Ответ для Andrey Cherepanov на комментарий #2) > > > (Ответ для Alexei Takaseev на комментарий #1) > > > > Не пойму в чем тут проблема. При наличии в системе более ранней мажорной > > > > версии, она более новой не замещается. И смысла еще одной сборки не вижу. > > > > > > При обновлении с p10 до p11 пакеты выносятся и нет возможности перенести > > > базу на новую версию. > > > > Погодите. Можно более конкретно с логами. Потому как еще со времен Master > > 2.2 автоматом обновления мажорных версий не производится. > > Это понятно! Для перехода на новую мажорную версию должны быть бинарники > старой, чтобы выгрузить дама базы и засосать его в новый > (https://www.postgresql.org/docs/10/upgrading.html). Так? > Вот старые бинарники и предлагается как contrib без расширений оставить в > репозитории. Бинарники от предыдущей версии перед установкой новой версии складываются в %_libdir/pgsql/backup. Сейчас нашел ошибку с копированием этих бинарников именно в 16-й ветке.
(Ответ для Alexei Takaseev на комментарий #7) > (Ответ для Andrey Cherepanov на комментарий #6) > > (Ответ для Alexei Takaseev на комментарий #5) > > > (Ответ для Andrey Cherepanov на комментарий #2) > > > > (Ответ для Alexei Takaseev на комментарий #1) > > > > > Не пойму в чем тут проблема. При наличии в системе более ранней мажорной > > > > > версии, она более новой не замещается. И смысла еще одной сборки не вижу. > > > > > > > > При обновлении с p10 до p11 пакеты выносятся и нет возможности перенести > > > > базу на новую версию. > > > > > > Погодите. Можно более конкретно с логами. Потому как еще со времен Master > > > 2.2 автоматом обновления мажорных версий не производится. > > > > Это понятно! Для перехода на новую мажорную версию должны быть бинарники > > старой, чтобы выгрузить дама базы и засосать его в новый > > (https://www.postgresql.org/docs/10/upgrading.html). Так? > > Вот старые бинарники и предлагается как contrib без расширений оставить в > > репозитории. > > Бинарники от предыдущей версии перед установкой новой версии складываются в > %_libdir/pgsql/backup. Сейчас нашел ошибку с копированием этих бинарников > именно в 16-й ветке. А можно тогда в свете этой информации написать раздел https://www.altlinux.org/PostgreSQL#Переход_на_новую_версию
Дело даже не в обновлении самого postgresql, а в принципиальной возможности на двух разных хостах с разными платформами каким-то образом на время поиметь одну версию Postgres для 1С. И потом уже целиком на новой платформе в рабочем порядке обновлять Postgres. Но не одновременно - это ад. В p10 у нас две сборки postgresql*-1C: 14 и 15. В Сизифе, а значит и p11 - только 16. А было бы 15 и 16 (15 как переходная) - вот так было бы хорошо.
(Ответ для Pavel Isopenko на комментарий #9) > Дело даже не в обновлении самого postgresql, а в принципиальной возможности > на двух разных хостах с разными платформами каким-то образом на время > поиметь одну версию Postgres для 1С. И потом уже целиком на новой платформе > в рабочем порядке обновлять Postgres. Но не одновременно - это ад. > > В p10 у нас две сборки postgresql*-1C: 14 и 15. В Сизифе, а значит и p11 - > только 16. А было бы 15 и 16 (15 как переходная) - вот так было бы хорошо. Зачем? pg_upgrade может спокойно обновить версию базы без промежуточных остановок. Специально для теста проделал это для базы 12-й версии, обновив ее до 16-й
(Ответ для Alexei Takaseev на комментарий #10) > Зачем? Чтобы получить временной лаг на случай обнаружения несовместимости с платформой 1С:Предприятие, и даже с прикладными решениями на её основе (именно их эксплуатация, если подумать, и есть цель). Напомню, как по проблеме с клиентом 1С на переходе p8-p9 мы пытались получить комментарий от 1С в течение девяти месяцев. > pg_upgrade может спокойно обновить версию базы без промежуточных > остановок. Специально для теста проделал это для базы 12-й версии, обновив > ее до 16-й Может. Однако это действие без заднего хода, ну разве что через бэкапы с ущербом по времени и репутации. Особенно если баз на сервере не одна-две, а одна-две сотни (мой случай). Предлагая оставлять в Сизифе крайнюю версию стабильного бранча, я имел в виду также то, что для этого вроде как не надо специально что-то делать. Достаточно не делать, а именно не удалять без явной необходимости. Такое возможно?
(Ответ для Pavel Isopenko на комментарий #11) > (Ответ для Alexei Takaseev на комментарий #10) > > > Зачем? > > Чтобы получить временной лаг на случай обнаружения несовместимости с > платформой 1С:Предприятие, и даже с прикладными решениями на её основе > (именно их эксплуатация, если подумать, и есть цель). Напомню, как по > проблеме с клиентом 1С на переходе p8-p9 мы пытались получить комментарий от > 1С в течение девяти месяцев. Были случаи, когда актуальные поддерживаемые версии платформы 1С имели несовместимость с новыми, заявленными как поддерживемые, версиями патченного PG? > > > pg_upgrade может спокойно обновить версию базы без промежуточных > > остановок. Специально для теста проделал это для базы 12-й версии, обновив > > ее до 16-й > > Может. Однако это действие без заднего хода, ну разве что через бэкапы с > ущербом по времени и репутации. Особенно если баз на сервере не одна-две, а > одна-две сотни (мой случай). Мажорный > > Предлагая оставлять в Сизифе крайнюю версию стабильного бранча, я имел в > виду также то, что для этого вроде как не надо специально что-то делать. > Достаточно не делать, а именно не удалять без явной необходимости. Такое > возможно?
(Ответ для Pavel Isopenko на комментарий #11) > (Ответ для Alexei Takaseev на комментарий #10) > > pg_upgrade может спокойно обновить версию базы без промежуточных > > остановок. Специально для теста проделал это для базы 12-й версии, обновив > > ее до 16-й > > Может. Однако это действие без заднего хода, ну разве что через бэкапы с > ущербом по времени и репутации. Особенно если баз на сервере не одна-две, а > одна-две сотни (мой случай). Мажорный переход это всегда путь без обратного хода для данных. Вернуться к старой версии можно только через сохраненный бэкап старых данных. Наличие старой версии этому не поможет. > > Предлагая оставлять в Сизифе крайнюю версию стабильного бранча, я имел в > виду также то, что для этого вроде как не надо специально что-то делать. > Достаточно не делать, а именно не удалять без явной необходимости. Такое > возможно? Вы предлагаете некую частную гипотетическую проблему решать дистрибутивным методом, который кратно увеличивает затраты на поддержку и сопровождение, без какой-либо реальной пользы.
(Ответ для Alexei Takaseev на комментарий #13) > > Вы предлагаете некую частную гипотетическую проблему решать дистрибутивным > методом, который кратно увеличивает затраты на поддержку и сопровождение, > без какой-либо реальной пользы. Всё, уже не предлагаю. Кратное увеличение затрат на поддержку - это аргумент. Если это так, то действительно не стоит.
