Доступны (http://www.postgresql.org/about/news/1590/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.4.3 (http://www.postgresql.org/docs/current/static/release-9-4-3....), 9.3.8 (http://www.postgresql.org/docs/current/static/release-9-3-8....), 9.2.12 (http://www.postgresql.org/docs/9.2/static/release-9-2-12.html), 9.1.17 (http://www.postgresql.org/docs/9.1/static/release-9-1-17.html) и 9.0.21 (http://www.postgresql.org/docs/current/static/release-9-0-21...). Выпуск обновлений для ветки 9.0 продлится (http://www.postgresql.org/support/versioning/) до сентября 2015 г., 9.1 до сентября 2016 г., 9.2 до сентября 2017 г., 9.3 до сентября 2018 г., 9.4 до декабря 2019 г. В новых выпусках устранена ошибка в реализации механизма fsync, которая может привести к невозможности запустить сервер после краха или восстановления из бинарной резервной копии. Проблема затрагивает конфигурации в которых в директории PGDATA размещены дополнительные файлы или директории, принадлежащие пользователю, отличному от "postgres", или недоступные на запись (подобное наблюдается в пакетах PostgreSQL 9.1 и 9.0 с SSL в Debian и Ubuntu). Если возник сбой с загрузкой PostgreSQL, обходным путём решения проблемы является временная смена прав доступа на недоступные на запись файлы в PGDATA на пользователя postgres.URL: http://www.postgresql.org/about/news/1590/
Новость: http://www.opennet.me/opennews/art.shtml?num=42367
> Выпуск обновлений для ветки 9.0 продлится до сентября 2015Черт побери! Когда же они ее убьют!!! Жду.
Ну да, она же просто мешает жить!
Просто сделано на века ...
человек написал "жду" вместо "ждём" -- учитесь, детки, как правильно высказывать своё мнение -- а то порядком поднадоели товарищи, говорящие о себе во множественном числе, дабы их мнение казалось более важным
Никто не в курсе, в PostgreSQL появился memory движок?
> Никто не в курсе, в PostgreSQL появился memory движок?зачем если есть tablespace?
И?
W?
> Никто не в курсе, в PostgreSQL появился memory движок?http://www.databasesoup.com/2015/02/running-with-scissors-mo...
> Note that these settings do not, in fact, disable all disk writes.Ну ну... Вы хоть сами то читали эту статью? Похоже что нет
>> Note that these settings do not, in fact, disable all disk writes.
> Ну ну... Вы хоть сами то читали эту статью? Похоже что нетtmpfs.
Для этого надо разобраться в структуре базы, чтобы перевести все операции, связанные с такой таблицей, в tmpfs раздел. Это всякие логи, журналы и т.п. У меня есть сомнения что в postgre найтивно можно создавать подобные конфигурации отдельно для каждой таблицы. Допустим даже и так. В придачу ко всему нужно позаботиться о восстановлении такой таблицы после перезагрузки сервера, для этого определенно нужен отдельный скрипт, функционалом базы такого не добиться. И так же необходимо отслеживать изменения структуры таблицы и делать бэкап - для этого тоже нужно писать скрипт, и притом совсем не тривиальный. Не знаю никого, кому бы подошел вариант с tmpfs. Это решение вильется в сплошную головную боль.
NOSQL inmemory субд полно, и ни у кого не возникает вопросов про безопасность данных. Почему с SQL базами всё иначе? Сейчас по фатку из SQL только mysql очень корявенько может хранить данные в памяти.
Oracle 12c
Еслиб здесь кого-то интересовало проприетарное по, этот ресурс назывался бы www.proprietarynet.ru
Потому что у тех кто их (ну за исключением MySQL) выбирает этот вопрос возникает.
На них видать и ориентируются.
Собственно движок inmemory database это такой сильно специализированный способ сделать масив доступный через сетевой сервис. В примитиве делается в любой RAID за несколько кликов мышкой. И дальше если надо подтачивается под свои мысли. Зачем оно же заточенное под чужие?
> Собственно движок inmemory database это такой сильно специализированный ...Ага, возможность выбирать устройство хранения - очень специализированная функция бд.
> способ сделать масив доступный через сетевой сервис.Звучит так, будто это единственная задача, которую может решить memory движок. А как же кэширование записи? А временные таблицы?
> И дальше если надо подтачивается под свои мысли. Зачем оно же заточенное под чужие?Причем здесь чужие мысли, если говорится о выборе устройства хранения базы? Вашу фразу прямым образом можно отнести и к хранению на жестком диске, -> для меня это узкоспециализированная и вообще неадекватная затея. И аргументов я приведу столько же, сколько и Вы. Т.ч. всё зависит от конкретной ситуации, и различать по узкоспециализированности хранение в озу и пзу неправильно.
> На них видать и ориентируются.Не думаю. Практика показывает ram намного безопаснее hdd. Тут скорее дело в недостатке времени и наличии более приоритетных задач. Как ни открою трекер - фиксят кучу багов, а таски годами висят.
> (подобное наблюдается в пакетах PostgreSQL 9.1 и 9.0 с SSL в Debian и Ubuntu)А где-либо ещё, кроме дебиана и производных, ухитрились так себе в ногу шмальнуть?