=)
1) Обновиться. Его давно переименовали в pg_wal. 2) Проверить слоты репликацыи и archive_command. В большынстве случаев разрастание wal означает, что где-то встала репликацыя или копирование этих данных, потому сервер ждёт, когда всё скопируется и ему разрешат это удалить.
спасибо уже разобрался =) не подскажете переход с 9.6 на более свежую версию безболезненный ? =)
Ну, changelog лучшэ прочитать от каждой промежуточной мажорной версии. Я вот непомню -- было вроде кардинальное изменение результатов нескольких unnest в SELECT. Плюс, сейчас, в 14, подсуропили -- дропать и пересоздавать stored с функцыями , array_append(), array_prepend(), array_cat(), array_position(), array_positions(), array_remove(), array_replace(), and width_bucket(). Но лучшэ сначала самому прочитать, потом на стэджэ прогнать все тэсты. В среднем -- функцый только добавляется, pg_upgrade нормально отрабатывает.
Зависит от качества тестирования и того, как вы используете СУБД. На одной стороне стоит orm-only использование с простейшими crud-запросами (для такой системы, скорее всего, всё пройдёт абсолютно безболезненно), на другой стороне - разработчики ide (им придётся дорабатывать всё что касается работы с pg_catalog). Системы, где есть сложные трёхстраничные запросы в БД или куча обработки на хранимках - где-то посередине (может быть наблюдаемое изменение в производительности как в лучшую, так и в худшую сторону), плюс если где-то завязались на системные штуки типа того же pg_catalog-а таблиц with oids (хотя так делать не рекомендуется уже в 9.6 вроде), может понадобиться доработка.
Обсуждают сегодня