Сформированы (https://www.postgresql.org/about/news/1851/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 10.4 (https://www.postgresql.org/docs/current/static/release-10-4....), 9.6.9 (http://www.postgresql.org/docs/current/static/release-9-6-9....), 9.5.13 (http://www.postgresql.org/docs/current/static/release-9-5-13...), 9.4.18 (http://www.postgresql.org/docs/current/static/release-9-4-18...) и 9.3.23 (http://www.postgresql.org/docs/current/static/release-9-3-23...), в которых представлена порция исправлений ошибок. Выпуск обновлений для ветки 9.3 продлится (http://www.postgresql.org/support/versioning/) до сентября 2018 г., 9.4 до декабря 2019 г., 9.5 до января 2021 г., 9.6 - до сентября 2021 года, 10 - до октября 2022 года.В обновлении устранена уязвимость (CVE-2018-1115), связанная с предоставлением общих привилегий (вместо привязки к администратору) для вызова функции pg_logfile_rotate(), устаревшего варианта pg_rotate_logfile() из contrib/adminpack. Уязвимость позволяет любому пользователю PostgreSQL инициировать ротацию лога, в случае если установлен adminpack. Для устранения уязвимости после установки обновления пользователям adminpack следует выполнить "ALTER EXTENSION adminpack UPDATE" для каждой БД.
Кроме того, исправлено более 50 ошибок (https://postgrespro.ru/docs/postgresql/10/release-10-4), например, устранена утечка памяти при выполнении операций слияния хэшей, решены проблемы с крахами при использовании "GROUPING SET", оптимизирована установка блокировок при выполнении autovacuum. Много исправлений связано с параллельным выполнением операций, в том числе устранена взаимная блокировка, возникающая при определённом использовании "CREATE INDEX CONCURRENTLY".
URL: https://www.postgresql.org/about/news/1851/
Новость: https://www.opennet.ru/opennews/art.shtml?num=48586
Правильно ли я понимаю ситуацию: если тебя устраивает 9.6 можно сидеть на ней ровно ещё 3 года и планировать миграцию только к окончанию этого срока? Запланированы ли новые релизы с киллeр-фичами на ближайшие 2 года?//странный у вас фильтр тут
Да, но я бы советовал начинать планировать миграцию хотя бы за полгода до окончания срока.
Каждая новая версия быстрее любой предыдущей на _типовом_ классе задач.
НО(!) не все расширения переписаны с прошлых версий на более новые. К примеру pg_shard последняя версия для 9.4 (переписывают на fwd), londista последняя версия 9.6 (заменяют логической репликациеей) и т.д.
Так что проверь что у вас используется из сторонних модулей и тогда принимай решения.
>Каждая новая версия быстрее любой предыдущей на _типовом_ классе задач.Выбравших РСУБД скорость не интересует. :) Ну давайте реалистично, какой прирост у 9.5 vs 10.3 ? Единицы процентов в сферическом вакууме. При миграции в nosql получишь разы.
Это если ваша задача ложится в рамки nosql.
> Это если ваша задача ложится в рамки nosql.У NOSQL нет рамок, это вам не РСУБД :))))
>> какой прирост у 9.5 vs 10.39.5._13_ vs 10._4_ (мериемся старшими версиями надеюсь?)
TLDR: Параллельные запросы ускорили (не для хайлоад) отзывчивость в 4-10 раз (count(*), select). Для хайлоада декларативное секционирование перераспределило нагрузку на IO диска.
Развернуто:
В число ключевых усовершенствований PostgreSQL 9.6 входят:
Параллельное выполнение последовательного сканирования, соединений и агрегатных вычислений
Предупреждение излишнего сканирования страниц при операциях очистки с заморозкой
При синхронной репликации стало возможным использовать несколько резервных серверов для увеличения надёжности
Полнотекстовый поиск теперь позволяет находить фразы (несколько соседних слов)
postgres_fdw теперь может выполнять на удалённой стороне соединение, сортировку, UPDATE и DELETE
Существенное увеличение производительности, особенно в части масштабируемости на многопроцессорных серверахПредыдущие пункты более подробно описаны в следующих разделах https://postgrespro.ru/docs/postgresql/9.6/release-9-6
В число ключевых усовершенствований PostgreSQL 10 входят:
Логическая репликация по схеме публикации/подписки
Декларативное секционирование таблиц
Улучшение распараллеливания запросов
Значительное увеличение общей производительности
Более сильная защита паролей с использованием SCRAM-SHA-256
Улучшенные средства мониторинга и управленияПредыдущие пункты более подробно описаны в следующих разделах https://postgrespro.ru/docs/postgresql/10/release-10
>> При миграции в nosql _получишь разы_.1) переучить всех разработчиков (не быстро, возможно)
2) переучить всех ПМ (очень не быстро, маловероятно)
3) переобучить всех клиентов (почти невозможно, стоит подыскивать новую нишу)
4) пересмотреть всю документацию, методологию, провести новые замеры всех типовых и комплексных операций, что бы планировать время нужное на разработку (проще взять вторую команду, если найдешь двойной годовой бюджет, который можно более эффективно вложить в старую команду, _работающую_ и кормящую тебя технологию).
Менеджер какой-то забрёл? :) Что значит "отзывчивость select"? Если время выполнения, то в Постгресе count(*) настолько тормозной по сравнению с например Монго, что его можно и в 100 раз ускорить :) всё остальное блабла. Когда Убер вернется на Постгрес, тогда и поговорим про прогресс в скорости :)>1) переучить всех разработчиков (не быстро, возможно)
>2) переучить всех ПМ (очень не быстро, маловероятно)
>3) переобучить всех клиентов (почти невозможно, стоит подыскивать новую нишу)Ога, особенно клиентов надо переучивать. А ещё бабушку с дедушкой :)
> Правильно ли я понимаю ситуацию: если тебя устраивает 9.6 можно сидеть на
> ней ровно ещё 3 годаЕсли ваш проект вообще не развивается, можно было влепить 9.2 из CentOS и вообще 10 лет не трогать.
Для вас развитие заключается в постоянном мигрировании используемой РСУБД с ветки на ветку? Бизнес-процессы обычно против пустых неоправданных трат.
>Бизнес-процессы обычно против пустых неоправданных тратБизнес-процессы не могут быть за или против :)))
А представители бизнеса очень часто непротив даже смены вендора, главное правильно идею преподнести :))) "оптимизации затрат на Х попугаев" или там "усилить аспект движения к интегральной компании" 8)))) в общем, то что миграции стоят денег это вообще не проблема, когда есть технические предпосылки. А когда их нет по 5 лет, то это то самое "проект не развивается". Увы и ах.
Рассуждаете как тот Убер, который имел довольно специфичные задачи и не осилив миграцию сделал ошибочные выводы.
>как тот Убер, который имел довольно специфичные задачи и не осилив миграцию сделал ошибочные выводыДа, да, Постгрес перестраивает все индексы на каждый апдейт и летает. А маргинальный Убер просто не осилил...
Пожалуй лучшая СУБД