Summary: | Просьба сохранить для бранча предыдущую версию пакета | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Pavel Isopenko <master> |
Component: | postgresql16-1C-contrib | Assignee: | Alexei Takaseev <taf> |
Status: | CLOSED WONTFIX | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | cas, taf |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux |
Description
Pavel Isopenko
2024-05-24 10:38:53 MSK
Не пойму в чем тут проблема. При наличии в системе более ранней мажорной версии, она более новой не замещается. И смысла еще одной сборки не вижу. (Ответ для 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) > > Вы предлагаете некую частную гипотетическую проблему решать дистрибутивным > методом, который кратно увеличивает затраты на поддержку и сопровождение, > без какой-либо реальной пользы. Всё, уже не предлагаю. Кратное увеличение затрат на поддержку - это аргумент. Если это так, то действительно не стоит. |