Обновление PostgreSQL 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23

09.10.2015 09:05

Доступны корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.4.5, 9.3.10, 9.2.14, 9.1.19 и 9.0.23, в которых устранено две уязвимости и представлена порция исправлений ошибок. Первая уязвимость (CVE-2015-5289) позволяет осуществить DoS-атаку через манипуляцию с данными в формате JSON или JSONB. Вторая уязвимость (CVE-2015-5288) позволяет прочитать содержимое нескольких байт памяти за пределами буфера функции crypt() при использовании опционального расширения pgCrypto. Кроме того, в различных подсистемах добавлена защита от потенциальных переполнений стека.

В новых выпусках также отключено по умолчанию повторное согласование уже установленных SSL-соединений. Устранена серия ошибок в коде обработки регулярных выражений, в частности, одна из ошибок могла привести к краху сервера при использовании сопоставлений LIKE и SIMILAR с регулярными выражениями высокого уровня вложенности. Устранена взаимная блокировка при помещении данных в WAL лог при включенной опции commit_delay и решены проблемы с блокировками при обновлении представлений. Исправлено несколько ошибок в реализациях PL/Python, PL/Perl и PL/Tcl. В libpq улучшена обработка ситуации нехватки памяти. Решены проблемы с поддержкой платформ Alpha, PPC, AIX и Solaris.

Одновременно представлена бета-версия PostgreSQL 9.5, которая ознаменовала готовность всех запланированных возможностей и переход на финальную стадию подготовки релиза.

исправить +17 +/–

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/43116-postgresql

Ключевые слова: postgresql

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (22)

1.1, Аноним (-), 13:36, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
>> Обновление PostgreSQL 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23 Для локалхоста лучше что?

2.2, Аноним (-), 13:47, 09/10/2015 [^] [^^] [^^^] [ответить]	+11 +/–
sqlite3

2.3, _KUL (ok), 14:01, 09/10/2015 [^] [^^] [^^^] [ответить]	+2 +/–
Тамошнему админу не настраивать внешние сетевые интерфейсы ...

1.4, xwild (ok), 16:14, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
И после выхода 9.5 они будут поддерживать уже 6 веток одновременно?

2.5, Andrey Mitrofanov (?), 17:33, 09/10/2015 [^] [^^] [^^^] [ответить]	–1 +/–
> И после выхода 9.5 они будут поддерживать уже 6 веток одновременно? Они там наверху написали, что 9.0 -- крайний раз.

3.7, . (?), 20:16, 09/10/2015 [^] [^^] [^^^] [ответить]	+/–
>This is also the final update release for major version 9.0. Утверждено. Ъ.

2.6, Аноним (-), 20:11, 09/10/2015 [^] [^^] [^^^] [ответить]	+3 +/–
http://www.postgresql.org/support/versioning/

1.8, Вареник (?), 20:35, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]	+/–
>> PostgreSQL 9.5 Прекрасно. Лучшая база из некластерных.

2.9, Я Ампер (?), 20:47, 09/10/2015 [^] [^^] [^^^] [ответить]	+/–
А из кластерных? И чем постгрес некластерный?

3.11, Аноним (-), 21:52, 09/10/2015 [^] [^^] [^^^] [ответить]	+/–
> А из кластерных? Postgres-XL Postgres-XC

1.10, Аноним (-), 21:50, 09/10/2015 [ответить] [﹢﹢﹢] [ · · · ]	+/–
Фрактальные индексы будут? B-Tree на помойку!!!

1.12, vitalif (ok), 01:13, 10/10/2015 [ответить] [﹢﹢﹢] [ · · · ]	–1 +/–
Хочу уже релиз 9.5, там наконец-то upsert есть ))

1.13, Аноним (-), 10:43, 10/10/2015 [ответить] [﹢﹢﹢] [ · · · ]	–2 +/–
In-Memory будет? Уже ведь везде есть!

2.14, Stax (ok), 17:14, 10/10/2015 [^] [^^] [^^^] [ответить]

+1 +/–

Поделитесь же с общественностью вашим списком SQL баз данных! Раз в них In-Memory везде.

А я вам скажу - из всех популярных клиент-серверных SQL БД поддержка In-Memory есть только в Oracle 12.1 и в DB2 (BLU). Ну еще зачатки в SQL Server, но с кучей ограничений и только для индексов, не для данных. По факту нигде, кроме оракла и DB2 нет. Для оракла опция In-Memory (доступна только для EE, разумеется) стоит $23,000 за каждое процессорное ядро, это вдобавок к стоимости самого Oracle EE, который тоже стоит, мягко говоря, не копейки. Ценник на DB2 сравним.

PostgreSQL, MySQL/MariaDB, Firebird - не существует свободных или по разумной стоимости (SQL Server, PostgreSQL Enterprise DB) SQL-решений с In Memory.

3.17, Bolk (?), 12:45, 11/10/2015 [^] [^^] [^^^] [ответить]	+/–
У MySQL есть: https://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html

4.18, Stax (ok), 14:38, 11/10/2015 [^] [^^] [^^^] [ответить]	+/–
Гм. И правда, сделали, правда ограничения напрягают. Теряем данные при перезагрузке сервера. Нет поддержки транзакций. Нет Foreign key - ну если это я могу понять, то как без транзакций разруливаются параллельные модификации? Нельзя длинные поля (напр. TEXT) положить в такую таблицу. Не, по сравнению с реализацией в том же Oracle это считай что "не сделали"...

5.22, Аноним (-), 15:19, 14/10/2015 [^] [^^] [^^^] [ответить]	+/–
Так и быть простим вам ваше невежество и будем считать что их нет.

2.15, Миша (??), 01:33, 11/10/2015 [^] [^^] [^^^] [ответить]	+2 +/–
Нормально настроенный pg -- in-memory чуть более чем полностью

3.16, Stax (ok), 03:44, 11/10/2015 [^] [^^] [^^^] [ответить]

+/–

Да ладно.

Простая задача: есть сервер, 128 Гб памяти, в нем небольшая база на 500 Гб (запросы бывают по всем таблицам базы). Есть желание, чтобы одна небольшая табличка на 10 гигов всегда была в оперативной памяти. И как же вы это сделаете?

Только не надо предлагать tablespace в /dev/shm, пожалуйста...

4.20, ъ (?), 01:39, 12/10/2015 [^] [^^] [^^^] [ответить]

+/–

>> И как же вы это сделаете?

500Гб рам дешевле чем 500Гб ssd. Если ваши запросы приносят больше денег при более быстром исполнении, то вы сами себе вредите используя недостаток ресурсов. Если же они никому не нужны, то и требовать их решать от форума смысла нет.

В правый столбик все что приносит деньги, в левый все что отнимает - если баланс больше нуля - то покупать новое железо, если отрицательный - закрывать проект или как инимум пересмотреть подход.

Как альтернатива - дать архитектору по шапке и использовать партиции, а не складывать все в одну 10Гб табличку, тогда мастер таблица будет скорее всего в рам.

Ну и сравнивать БД инмемори (с достаточным кол-вом рам) с сепарейтмемори (с недостаточным кол-вом рам) не корректно.

Ну а если не для бизнеса, а для себя любимого, то "PostgreSQL foreign data wrapper for Redis" вам в помощь.

4.21, Аноним (-), 00:12, 13/10/2015 [^] [^^] [^^^] [ответить]	+1 +/–
tablespace в tmpfs

1.19, Nas_tradamus (ok), 15:42, 11/10/2015 [ответить] [﹢﹢﹢] [ · · · ]	+/–
>>Устранена взаимная блокировка при помещении данных в WAL лог при включенной опции commit_delay Вот это да. Не замечал. Где-то на 40 серверах включен commit_delay и всё нормально. Интересны последствия этой взаимоблокировки.

Добавить комментарий

Текст: