Комментарии
А как-же: «Хабр — вне политики» ;-)?
ЗЫ: Хотелось, чтобы так оно и было (как на фото).
Хабр вне политики — имеется ввиду российская политика. Американскую, китайскую, европейскую — можно обсуждать сколько угодно. На КПДВ ни капли не российские политики, то какие могут быть претензии?
в том что значит, голову надо включать. Без политики это значит без любой политики, фотка лукашенко и его сына совершенно лишняя
может, фотка и лишняя, но комментарии привлекла(
...
(в принципе, ничего плохого не вижу, мало ли мемчиков в инете… )
Хабр вне политики — имеется ввиду российская политика.

Где написано, что не российская политика — это не политика?

Вот тебе на, в этом году обновил несколько десятков СУБД Postgres до 11 версии через pg_upgrade. Кажется, нам везло, проблем никогда не возникало. Даже не подозревал о таких нюансах.

Спасибо за статью. Теперь появился страх перед обновлениями.
Расслабьтесь, это платный клиент. Им и новости воровать можно без указания первоисточника, как в «лучшие» времена гиктаймза, и политику припихнуть куда не надо, да и вообще…

Еще особенность при обновлении с 9.6 и меньше до 10.0 и старше:
до обновления


 select to_timestamp('2020-06-01 10:12:01.1234', 'YYYY-MM-DD HH24:MI:SS.MS');
        to_timestamp
----------------------------
 2020-06-01 10:12:02.234+00
(1 row)

после обновления:


select to_timestamp('2020-06-01 10:12:01.1234', 'YYYY-MM-DD HH24:MI:SS.MS');
ERROR:  date/time field value out of range: "2020-06-01 10:12:01.1234"

Да, запрос изначально ошибочный, но показывает что тестировать обновления всегда надо тщательно, т.к. никогда не предугадаешь что поломается.

Потому что MS это 0-999, так написано в документации. Возможно разрабочик хотел использовать US. Прошлое поведение просто увеличивало значение секунды при переполнении MS, что на самом деле странно.

Сегодня на пять часов запланирован maintenance window, будем тестировать плейбуки.

Гайд был написан для внутреннего использования, у нас на столько старых БД нету.

Почему вы президентство баном называете?
disclaimer
На всякий случай поясняю, я петросяню :)
Если заранее на стенде разработки держать версию PostgreSQL более свежую — большая часть граблей в хранимках, изменений в стандартных функциях, расширениях вполне может быть выловлена. Ровно как и раскатка структуры бд на новой версии выявит проблемы, на которых pg_basebackup гарантированно споткнется.
На «кошках» можно попробовать кластер также через pg_upgrade провести(ИМХО, с ключом -k самый быстрый способ обновиться).
Про обновление через логич. репликацию — годный вариант обойти проблему пересборки индексов, но есть проблема переноса blob(бывает и такое в бд держат).
Более информативно было вроде как тут.

C pg_upgrade немало проблем, все они помечены "еще один камушек в сторону pg_upgrade".

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.