Доступны (http://www.postgresql.org/about/news/1615/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.4.5 (http://www.postgresql.org/docs/current/static/release-9-4-5....), 9.3.10 (http://www.postgresql.org/docs/current/static/release-9-3-10...), 9.2.14 (http://www.postgresql.org/docs/9.2/static/release-9-2-14.html), 9.1.19 (http://www.postgresql.org/docs/9.1/static/release-9-1-19.html) и 9.0.23 (http://www.postgresql.org/docs/current/static/release-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.
Одновременно представлена (http://www.postgresql.org/about/news/1614/) бета-версия PostgreSQL 9.5, которая ознаменовала готовность всех запланированных возможностей (https://www.opennet.me/opennews/art.shtml?num=42555) и переход на финальную стадию подготовки релиза.
URL: http://www.postgresql.org/about/news/1615/
Новость: http://www.opennet.me/opennews/art.shtml?num=43116
>> Обновление PostgreSQL 9.4.5, 9.3.10, 9.2.14, 9.1.19, 9.0.23Для локалхоста лучше что?
sqlite3
Тамошнему админу не настраивать внешние сетевые интерфейсы ...
И после выхода 9.5 они будут поддерживать уже 6 веток одновременно?
> И после выхода 9.5 они будут поддерживать уже 6 веток одновременно?Они там наверху написали, что 9.0 -- крайний раз.
>This is also the final update release for major version 9.0.Утверждено.
Ъ.
http://www.postgresql.org/support/versioning/
>> PostgreSQL 9.5Прекрасно. Лучшая база из некластерных.
А из кластерных? И чем постгрес некластерный?
> А из кластерных?Postgres-XL
Postgres-XC
Фрактальные индексы будут?B-Tree на помойку!!!
Хочу уже релиз 9.5, там наконец-то upsert есть ))
In-Memory будет? Уже ведь везде есть!
Поделитесь же с общественностью вашим списком 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.
У MySQL есть: https://dev.mysql.com/doc/refman/5.0/en/memory-storage-engin...
Гм. И правда, сделали, правда ограничения напрягают. Теряем данные при перезагрузке сервера. Нет поддержки транзакций. Нет Foreign key - ну если это я могу понять, то как без транзакций разруливаются параллельные модификации? Нельзя длинные поля (напр. TEXT) положить в такую таблицу.
Не, по сравнению с реализацией в том же Oracle это считай что "не сделали"...
Так и быть простим вам ваше невежество и будем считать что их нет.
Нормально настроенный pg -- in-memory чуть более чем полностью
Да ладно.Простая задача: есть сервер, 128 Гб памяти, в нем небольшая база на 500 Гб (запросы бывают по всем таблицам базы). Есть желание, чтобы одна небольшая табличка на 10 гигов всегда была в оперативной памяти. И как же вы это сделаете?
Только не надо предлагать tablespace в /dev/shm, пожалуйста...
>> И как же вы это сделаете?500Гб рам дешевле чем 500Гб ssd. Если ваши запросы приносят больше денег при более быстром исполнении, то вы сами себе вредите используя недостаток ресурсов. Если же они никому не нужны, то и требовать их решать от форума смысла нет.
В правый столбик все что приносит деньги, в левый все что отнимает - если баланс больше нуля - то покупать новое железо, если отрицательный - закрывать проект или как инимум пересмотреть подход.
Как альтернатива - дать архитектору по шапке и использовать партиции, а не складывать все в одну 10Гб табличку, тогда мастер таблица будет скорее всего в рам.
Ну и сравнивать БД инмемори (с достаточным кол-вом рам) с сепарейтмемори (с недостаточным кол-вом рам) не корректно.
Ну а если не для бизнеса, а для себя любимого, то "PostgreSQL foreign data wrapper for Redis" вам в помощь.
tablespace в tmpfs
>>Устранена взаимная блокировка при помещении данных в WAL лог при включенной опции commit_delayВот это да. Не замечал. Где-то на 40 серверах включен commit_delay и всё нормально. Интересны последствия этой взаимоблокировки.