URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 102905
[ Назад ]

Исходное сообщение
"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "

Отправлено opennews , 04-Июн-15 22:28 
Доступны (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


Содержание

Сообщения в этом обсуждении
"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено fi , 04-Июн-15 22:28 
> Выпуск обновлений для ветки 9.0 продлится до сентября 2015

Черт побери! Когда же они ее убьют!!! Жду.


"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено imprtat , 04-Июн-15 23:33 
Ну да, она же просто мешает жить!

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено _KUL , 05-Июн-15 05:06 
Просто сделано на века ...

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Нанобот , 05-Июн-15 08:46 
человек написал "жду" вместо "ждём" -- учитесь, детки, как правильно высказывать своё мнение -- а то порядком поднадоели товарищи, говорящие о себе во множественном числе, дабы их мнение казалось более важным

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 09:30 
Никто не в курсе, в PostgreSQL появился memory движок?

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено pavel_simple , 05-Июн-15 09:37 
> Никто не в курсе, в PostgreSQL появился memory движок?

зачем если есть tablespace?


"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 10:37 
И?

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Fantomas , 08-Июн-15 17:20 
W?

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Andrey Mitrofanov , 05-Июн-15 09:39 
> Никто не в курсе, в PostgreSQL появился memory движок?

http://www.databasesoup.com/2015/02/running-with-scissors-mo...


"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 10:36 
> Note that these settings do not, in fact, disable all disk writes.

Ну ну... Вы хоть сами то читали эту статью? Похоже что нет


"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Andrey Mitrofanov , 05-Июн-15 10:43 
>> Note that these settings do not, in fact, disable all disk writes.
> Ну ну... Вы хоть сами то читали эту статью? Похоже что нет

tmpfs.


"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 13:56 
Для этого надо разобраться в структуре базы, чтобы перевести все операции, связанные с такой таблицей, в tmpfs раздел. Это всякие логи, журналы и т.п. У меня есть сомнения что в postgre найтивно можно создавать подобные конфигурации отдельно для каждой таблицы. Допустим даже и так. В придачу ко всему нужно позаботиться о восстановлении такой таблицы после перезагрузки сервера, для этого определенно нужен отдельный скрипт, функционалом базы такого не добиться. И так же необходимо отслеживать изменения структуры таблицы и делать бэкап - для этого тоже нужно писать скрипт, и притом совсем не тривиальный. Не знаю никого, кому бы подошел вариант с tmpfs. Это решение вильется в сплошную головную боль.

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 10:40 
NOSQL inmemory субд полно, и ни у кого не возникает вопросов про безопасность данных. Почему с SQL базами всё иначе? Сейчас по фатку из SQL только mysql очень корявенько может хранить данные в памяти.

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено yetanotheranonym , 05-Июн-15 10:58 
Oracle 12c

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 11:57 
Еслиб здесь кого-то интересовало проприетарное по, этот ресурс назывался бы www.proprietarynet.ru

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено КО , 05-Июн-15 14:51 
Потому что у тех кто их (ну за исключением MySQL) выбирает этот вопрос возникает.
На них видать и ориентируются.
Собственно движок inmemory database это такой сильно специализированный способ сделать масив доступный через сетевой сервис. В примитиве делается в любой RAID за несколько кликов мышкой. И дальше если надо подтачивается под свои мысли. Зачем оно же заточенное под чужие?

"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 16:32 
> Собственно движок inmemory database это такой сильно специализированный ...

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

Звучит так, будто это единственная задача, которую может решить memory движок. А как же кэширование записи? А временные таблицы?
> И дальше если надо подтачивается под свои мысли. Зачем оно же заточенное под чужие?

Причем здесь чужие мысли, если говорится о выборе устройства хранения базы? Вашу фразу прямым образом можно отнести и к хранению на жестком диске, -> для меня это узкоспециализированная и вообще неадекватная затея. И аргументов я приведу столько же, сколько и Вы. Т.ч. всё зависит от конкретной ситуации, и различать по узкоспециализированности хранение в озу и пзу неправильно.


"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Аноним , 05-Июн-15 17:51 
> На них видать и ориентируются.

Не думаю. Практика показывает ram намного безопаснее hdd. Тут скорее дело в недостатке времени и наличии более приоритетных задач. Как ни открою трекер - фиксят кучу багов, а таски годами висят.


"Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21 "
Отправлено Michael Shigorin , 05-Июн-15 09:44 
> (подобное наблюдается в пакетах PostgreSQL 9.1 и 9.0 с SSL в Debian и Ubuntu)

А где-либо ещё, кроме дебиана и производных, ухитрились так себе в ногу шмальнуть?