https://mobile.opennet.me/openforum/vsluhforumID3/102905.html Доступны (http://www.postgresql.org/about/news/1590/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.4.3 (http://www.postgresql.org/docs/current/static/release-9-4-3.html), 9.3.8 (http://www.postgresql.org/docs/current/static/release-9-3-8.html), 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.html). Выпуск обновлений для ветки 9.0 продлится (http://www.postgresql.org/support/versioning/) до сентября 2015 г., 9.1 до сентября 2016 г., 9.2 до сентября 2017 г., 9.3 до сентября 2018 г., 9.4 до декабря 2019 г. В новых выпусках устранена ошибка в реализации механизма fsync, которая может привести к невозможности запустить сервер после краха или восстановления из бинарной резервной копии. Проблема затрагивает конфигурации в которых в директории PGDATA размещены дополнительные файлы или директории, принадлежащие пользователю, от https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#22 Mon, 08 Jun 2015 14:20:46 GMT W?<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#21 Fri, 05 Jun 2015 14:51:59 GMT &gt; На них видать и ориентируются.<br><br>Не думаю. Практика показывает ram намного безопаснее hdd. Тут скорее дело в недостатке времени и наличии более приоритетных задач. Как ни открою трекер - фиксят кучу багов, а таски годами висят.<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#20 Fri, 05 Jun 2015 13:32:03 GMT &gt; Собственно движок inmemory database это такой сильно специализированный ... <br><br>Ага, возможность выбирать устройство хранения - очень специализированная функция бд.<br>&gt; способ сделать масив доступный через сетевой сервис.<br><br>Звучит так, будто это единственная задача, которую может решить memory движок. А как же кэширование записи? А временные таблицы?<br>&gt; И дальше если надо подтачивается под свои мысли. Зачем оно же заточенное под чужие?<br><br>Причем здесь чужие мысли, если говорится о выборе устройства хранения базы? Вашу фразу прямым образом можно отнести и к хранению на жестком диске, -&gt; для меня это узкоспециализированная и вообще неадекватная затея. И аргументов я приведу столько же, сколько и Вы. Т.ч. всё зависит от конкретной ситуации, и различать по узкоспециализированности хранение в озу и пзу неправильно.<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#18 Fri, 05 Jun 2015 11:51:58 GMT Потому что у тех кто их (ну за исключением MySQL) выбирает этот вопрос возникает.<br>На них видать и ориентируются.<br> Собственно движок inmemory database это такой сильно специализированный способ сделать масив доступный через сетевой сервис. В примитиве делается в любой RAID за несколько кликов мышкой. И дальше если надо подтачивается под свои мысли. Зачем оно же заточенное под чужие?<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#16 Fri, 05 Jun 2015 10:56:46 GMT Для этого надо разобраться в структуре базы, чтобы перевести все операции, связанные с такой таблицей, в tmpfs раздел. Это всякие логи, журналы и т.п. У меня есть сомнения что в postgre найтивно можно создавать подобные конфигурации отдельно для каждой таблицы. Допустим даже и так. В придачу ко всему нужно позаботиться о восстановлении такой таблицы после перезагрузки сервера, для этого определенно нужен отдельный скрипт, функционалом базы такого не добиться. И так же необходимо отслеживать изменения структуры таблицы и делать бэкап - для этого тоже нужно писать скрипт, и притом совсем не тривиальный. Не знаю никого, кому бы подошел вариант с tmpfs. Это решение вильется в сплошную головную боль.<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#15 Fri, 05 Jun 2015 08:57:21 GMT Еслиб здесь кого-то интересовало проприетарное по, этот ресурс назывался бы www.proprietarynet.ru<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#13 Fri, 05 Jun 2015 07:58:06 GMT Oracle 12c<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#12 Fri, 05 Jun 2015 07:43:41 GMT &gt;&gt; Note that these settings do not, in fact, disable all disk writes.<br>&gt; Ну ну... Вы хоть сами то читали эту статью? Похоже что нет <br><br>tmpfs.<br> https://mobile.opennet.me/openforum/vsluhforumID3/102905.html#11 Fri, 05 Jun 2015 07:40:50 GMT NOSQL inmemory субд полно, и ни у кого не возникает вопросов про безопасность данных. Почему с SQL базами всё иначе? Сейчас по фатку из SQL только mysql очень корявенько может хранить данные в памяти.<br>