https://mobile.opennet.me/openforum/vsluhforumID3/105045.html Доступны (http://www.postgresql.org/about/news/1615/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.4.5 (http://www.postgresql.org/docs/current/static/release-9-4-5.html), 9.3.10 (http://www.postgresql.org/docs/current/static/release-9-3-10.html), 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.html), в которых устранено две уязвимости и представлена порция исправлений ошибок. Первая уязвимость (CVE-2015-5289) позволяет осуществить DoS-атаку через манипуляцию с данными в формате JSON или JSONB. Вторая уязвимость (CVE-2015-5288) позволяет прочитать содержимое нескольких байт памяти за пределами буфера функции crypt() при использовании опционального расширения pgCrypto. Кроме того, в различных подсистемах добавлена защита от потенциальных переполнений стека.<br><br><br> В новых выпусках также отключено по умолчанию повторное со https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#22 Wed, 14 Oct 2015 12:19:48 GMT Так и быть простим вам ваше невежество и будем считать что их нет.<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#21 Mon, 12 Oct 2015 21:12:35 GMT tablespace в tmpfs<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#20 Sun, 11 Oct 2015 22:39:13 GMT &gt;&gt; И как же вы это сделаете?<br><br>500Гб рам дешевле чем 500Гб ssd. Если ваши запросы приносят больше денег при более быстром исполнении, то вы сами себе вредите используя недостаток ресурсов. Если же они никому не нужны, то и требовать их решать от форума смысла нет.<br><br>В правый столбик все что приносит деньги, в левый все что отнимает - если баланс больше нуля - то покупать новое железо, если отрицательный - закрывать проект или как инимум пересмотреть подход.<br><br>Как альтернатива - дать архитектору по шапке и использовать партиции, а не складывать все в одну 10Гб табличку, тогда мастер таблица будет скорее всего в рам. <br><br>Ну и сравнивать БД инмемори (с достаточным кол-вом рам) с сепарейтмемори (с недостаточным кол-вом рам) не корректно.<br><br>Ну а если не для бизнеса, а для себя любимого, то "PostgreSQL foreign data wrapper for Redis" вам в помощь.<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#19 Sun, 11 Oct 2015 12:42:03 GMT &gt;&gt;Устранена взаимная блокировка при помещении данных в WAL лог при включенной опции commit_delay<br><br>Вот это да. Не замечал. Где-то на 40 серверах включен commit_delay и всё нормально. Интересны последствия этой взаимоблокировки.<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#18 Sun, 11 Oct 2015 11:38:59 GMT Гм. И правда, сделали, правда ограничения напрягают. Теряем данные при перезагрузке сервера. Нет поддержки транзакций. Нет Foreign key - ну если это я могу понять, то как без транзакций разруливаются параллельные модификации? Нельзя длинные поля (напр. TEXT) положить в такую таблицу.<br>Не, по сравнению с реализацией в том же Oracle это считай что "не сделали"...<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#17 Sun, 11 Oct 2015 09:45:09 GMT У MySQL есть: https://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#16 Sun, 11 Oct 2015 00:44:09 GMT Да ладно.<br><br>Простая задача: есть сервер, 128 Гб памяти, в нем небольшая база на 500 Гб (запросы бывают по всем таблицам базы). Есть желание, чтобы одна небольшая табличка на 10 гигов всегда была в оперативной памяти. И как же вы это сделаете?<br><br>Только не надо предлагать tablespace в /dev/shm, пожалуйста...<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#15 Sat, 10 Oct 2015 22:33:45 GMT Нормально настроенный pg -- in-memory чуть более чем полностью<br> https://mobile.opennet.me/openforum/vsluhforumID3/105045.html#14 Sat, 10 Oct 2015 14:14:55 GMT Поделитесь же с общественностью вашим списком SQL баз данных! Раз в них In-Memory везде.<br><br>А я вам скажу - из всех популярных клиент-серверных SQL БД поддержка In-Memory есть только в Oracle 12.1 и в DB2 (BLU). Ну еще зачатки в SQL Server, но с кучей ограничений и только для индексов, не для данных. По факту нигде, кроме оракла и DB2 нет. Для оракла опция In-Memory (доступна только для EE, разумеется) стоит $23,000 за каждое процессорное ядро, это вдобавок к стоимости самого Oracle EE, который тоже стоит, мягко говоря, не копейки. Ценник на DB2 сравним.<br><br>PostgreSQL, MySQL/MariaDB, Firebird - не существует свободных или по разумной стоимости (SQL Server, PostgreSQL Enterprise DB) SQL-решений с In Memory.<br>