Сформированы (https://www.postgresql.org/about/news/1829/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 10.2 (https://www.postgresql.org/docs/current/static/release-10-2....), 9.6.7 (http://www.postgresql.org/docs/current/static/release-9-6-7....), 9.5.11 (http://www.postgresql.org/docs/current/static/release-9-5-11...), 9.4.16 (http://www.postgresql.org/docs/current/static/release-9-4-16...) и 9.3.21 (http://www.postgresql.org/docs/current/static/release-9-3-21...), в которых представлена порция исправлений ошибок. Выпуск обновлений для ветки 9.3 продлится (http://www.postgresql.org/support/versioning/) до сентября 2018 г., 9.4 до декабря 2019 г., 9.5 до января 2021 г., 9.6 - до сентября 2021 года, 10 - до октября 2022 года.
В обновлении устранено более 60 ошибок (https://postgrespro.ru/docs/postgresql/10/release-10-2), в том числе улучшена работа параллельных запросов (устранена взаимная блокировка при одновременном выполнении "CREATE INDEX CONCURRENTLY") и репликации (налажена работа триггеров при логической репликации и устранено состояние гонки при удалении источника репликации), а также решены проблемы в коде VACUUM, GIN-индексов и hash-индексов, которые потенциально могли привести к повреждению данных. Устранены две уязвимости:
- CVE-2018-1052 (https://security-tracker.debian.org/tracker/CVE-2018-1052) - некорректная обработка ключей секционирования (https://www.postgresql.org/docs/10/static/ddl-partitioning.html), содержащих несколько выражений, позволявшая получить содержимое произвольных областей памяти рабочего процесса;- CVE-2018-1053 (https://security-tracker.debian.org/tracker/CVE-2018-1053) - создание в процессе работы pg_upgrade временных файлов, доступных всем на чтение (во временных файлах могут содержаться конфиденциальные данные, такие как поля с паролями).
URL: https://www.postgresql.org/about/news/1829/
Новость: http://www.opennet.ru/opennews/art.shtml?num=48043
>> также решены проблемы в коде VACUUM, GIN-индексов и hash-индексов, которые потенциально могли привести к повреждению данныхИ после такого товарищи из Pg сообщества еще будут брызгать слюнами, что мол переходите на Pg, она бесплатная и самая надежная?
Я бы рад, но перспектива потери данных не очень радует. Сколько еще таких граблей таиться в закромах?
В предыдущем релизе была эта же строчка, может забыли удалить? :)Лично я (а за мной и Сбербанк) перешёл на "хранить всё в ОЗУ". :)
> перешёл на "хранить всё в ОЗУ".Естественно, у тебя ж мозг маленький.
>Лично я (а за мной и Сбербанк) перешёл на "хранить всё в ОЗУ". :)Ну то есть синк на диск у вас реализован ... тобой? 8-o
RIP Сбербанк! А ведь мог бы жить :-\
>потенциально могли привести к повреждению данных
>самая надежнаяОдно другому не противоречит.
Ваш цэп.
Покупайте Oracle, это избавит Вас от мук осведомлённости о наличии багов.
Ещё у Орацле забавная политика обновлений. Ты репортишь data loss, через n месяцев тебе рожают патч. И этот патч НЕ тиражируется на остальных клиентов, если они не репортят data loss. Соответственно, на граблю должен наступить КАЖДЫЙ :)Информация с официальных курсов, сам только ворованный ковырял.
> Ты репортишь data loss, через n месяцев тебе рожают патч. И этот патч НЕ тиражируется на
> остальных клиентов, если они не репортят data loss.потому что неизвестно, не приведет ли он к каким-то еще проблемам у этих остальных клиентов - там, где раньше у них (в силу другой совершенно конфигурации, других нагрузок и других задач) ничего не терялось. Протестировать все это _невозможно_. В том числе потому, что ты не хочешь дать ораклу копию своих данных и своих программ, а они могут быть такими, что их разработчикам этот кошмар и не снился.
это обычный подход большинства коммерческих вендоров.
В следующую версию, если патч достаточно критичен и не слишком мутен, его, скорее всего включат.
Но оракл не та система, которую апгрейдят на новые версии.
У твоих любимых мелкосаксов - всё так же. На ОЗЪ - тоже :(
https://geektimes.ru/post/298003/
>>> также решены проблемы в коде VACUUM, GIN-индексов и hash-индексов, которые потенциально могли привести к повреждению данных
> И после такого товарищи из Pg сообщества еще будут брызгать слюнами, что
> мол переходите на Pg, она бесплатная и самая надежная?
> Я бы рад, но перспектива потери данных не очень радует. Сколько еще
> таких граблей таиться в закромах?Оставлять комментарии в темах в которых не разбираешься — плохой тон. Подобные комментарии дилетантов только замусоривают обсуждение. Не надо так.
>И после такого товарищи из Pg сообщества еще будут брызгать слюнами, что мол переходите на Pg, она бесплатная и самая надежная?Нет, мы спокойно и медленно спустимся с горы :) Массажируй ...
>Я бы рад, но перспектива потери данных не очень радует.
Ты не сможешь. Тут мозг нужен :) Но ты не плач - за тебя всё умные дяденьки сделают :)
>Сколько еще таких граблей таиться в закромах?Немало И что? Если бы хоть малейшее представление о теме имел - ну там был бы подписан _куда-надо_ у ораклов и\или мЫсЫ дЫбЫ :) - ты бы по ночам спать бы не смог, мнительный ты наш (С) :)
Да, теперь то всё устранили. mysql повержен окончательно
>а также решены проблемы в коде VACUUMСтранно, что за проблемы в том, чего уже "давно нет, было в 7.* при Чапаеве"? :)
>>а также решены проблемы в коде VACUUM
> Странно, что за проблемы в том, чего уже "давно нет, было в
> 7.* при Чапаеве"? :)https://www.postgresql.org/docs/current/static/bookindex.htm...
Спили мушку, сынок.
...или? Не пиши из будущего, венри Машину на Л0Р.
https://postgr.es/p/40G
https://postgr.es/p/3_r
Что в Слоне нет VACUUM заявляли местные эксперты в ветке про Firebird, а не я.Хотя, я тоже не делаю VACUUM в своих паре Postgres 9.6, потому что не делаю DELETE. Шах и мат вам, Монгисты!
Если вы вообще делаете update, то вакуум вам тоже нужен
> Если вы вообще делаете update, то вакуум вам тоже нужензависит от того, какой именно и чего update. Часто autovacuum (который все еще никуда не девался) справляется, vacuum full ; reindex... - действительно, не нужен.
Главное, не использовать ничего сложного - key/value наше всьо (и никаких сложных индексов по неуникальным выборкам!)
> я тоже не делаю VACUUM в своих паре Postgres 9.6, потому что не делаю DELETEУ меня для тебя плохие новости
>>а также решены проблемы в коде VACUUM
> Странно, что за проблемы в том, чего уже "давно нет, было в
> 7.* при Чапаеве"? :)ффсе нормально, скоро в очередной раз объявим что уж в следующей версии - точно-точно не будет, и да, точно-точно deprecated, не вздумайте пользоваться. Что, база сожрала сто терабайт и дальше растет? Ну...эта...только потом не жалуйтесь, вот же, написано - deprecated!
>>>а также решены проблемы в коде VACUUM
>> Странно, что за проблемы в том, чего уже "давно нет, было в
>> 7.* при Чапаеве"? :)
> ффсе нормально, скоро в очередной раз объявим что уж в следующей версии
> - точно-точно не будет, и да, точно-точно deprecated, не вздумайте пользоваться.
> Что, база сожрала сто терабайт и дальше растет? Ну...эта...только потом не
> жалуйтесь, вот же, написано - deprecated!Вы что-то не так поняли или перепутали.
>>а также решены проблемы в коде VACUUMони помалу переносят все в авто-вакуум :)
Ну а у "больших" просто уже перенесенно. Так или иначе но GC происходит у всех.
Сбой недавно был в сбере... Не работал сбер онлайн. Я сразу понял, что это GridGain виноват
> такие как поля с паролямиНе учите людей плохому!