The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Обновление PostgreSQL 9.4.3, 9.3.8, 9.2.12, 9.1.17, 9.0.21

04.06.2015 21:47

Доступны корректирующие обновления для всех поддерживаемых веток PostgreSQL: 9.4.3, 9.3.8, 9.2.12, 9.1.17 и 9.0.21. Выпуск обновлений для ветки 9.0 продлится до сентября 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.

  1. Главная ссылка к новости (http://www.postgresql.org/abou...)
  2. OpenNews: В недавнем обновлении СУБД PostgreSQL выявлена неприятная ошибка
  3. OpenNews: Обновление PostgreSQL 9.4.2, 9.3.7, 9.2.11, 9.1.16, 9.0.20
  4. OpenNews: В СУБД PostgreSQL включена реализация UPSERT
  5. OpenNews: Создатель СУБД PostgreSQL удостоен премии Тьюринга
  6. OpenNews: Обновление PostgreSQL 9.4.1, 9.3.6, 9.2.10, 9.1.15, 9.0.19 с устранением уязвимостей
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/42367-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (19) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, fi (ok), 22:28, 04/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    > Выпуск обновлений для ветки 9.0 продлится до сентября 2015

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

     
     
  • 2.2, imprtat (ok), 23:33, 04/06/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну да, она же просто мешает жить!
     
  • 2.3, _KUL (ok), 05:06, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Просто сделано на века ...
     
  • 2.4, Нанобот (ok), 08:46, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +9 +/
    человек написал "жду" вместо "ждём" -- учитесь, детки, как правильно высказывать своё мнение -- а то порядком поднадоели товарищи, говорящие о себе во множественном числе, дабы их мнение казалось более важным
     

  • 1.5, Аноним (-), 09:30, 05/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Никто не в курсе, в PostgreSQL появился memory движок?
     
     
  • 2.6, pavel_simple (ok), 09:37, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Никто не в курсе, в PostgreSQL появился memory движок?

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

     
     
  • 3.10, Аноним (-), 10:37, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И?
     
     
  • 4.22, Fantomas (??), 17:20, 08/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    W?
     
  • 2.7, Andrey Mitrofanov (?), 09:39, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Никто не в курсе, в PostgreSQL появился memory движок?

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

     
     
  • 3.9, Аноним (-), 10:36, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Note that these settings do not, in fact, disable all disk writes.

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

     
     
  • 4.12, Andrey Mitrofanov (?), 10:43, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Note that these settings do not, in fact, disable all disk writes.
    > Ну ну... Вы хоть сами то читали эту статью? Похоже что нет

    tmpfs.

     
     
  • 5.16, Аноним (-), 13:56, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Для этого надо разобраться в структуре базы, чтобы перевести все операции, связанные с такой таблицей, в tmpfs раздел. Это всякие логи, журналы и т.п. У меня есть сомнения что в postgre найтивно можно создавать подобные конфигурации отдельно для каждой таблицы. Допустим даже и так. В придачу ко всему нужно позаботиться о восстановлении такой таблицы после перезагрузки сервера, для этого определенно нужен отдельный скрипт, функционалом базы такого не добиться. И так же необходимо отслеживать изменения структуры таблицы и делать бэкап - для этого тоже нужно писать скрипт, и притом совсем не тривиальный. Не знаю никого, кому бы подошел вариант с tmpfs. Это решение вильется в сплошную головную боль.
     
  • 2.11, Аноним (-), 10:40, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    NOSQL inmemory субд полно, и ни у кого не возникает вопросов про безопасность данных. Почему с SQL базами всё иначе? Сейчас по фатку из SQL только mysql очень корявенько может хранить данные в памяти.
     
     
  • 3.13, yetanotheranonym (?), 10:58, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Oracle 12c
     
     
  • 4.15, Аноним (-), 11:57, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Еслиб здесь кого-то интересовало проприетарное по, этот ресурс назывался бы www.proprietarynet.ru
     
  • 3.18, КО (?), 14:51, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Потому что у тех кто их (ну за исключением MySQL) выбирает этот вопрос возникает.
    На них видать и ориентируются.
    Собственно движок inmemory database это такой сильно специализированный способ сделать масив доступный через сетевой сервис. В примитиве делается в любой RAID за несколько кликов мышкой. И дальше если надо подтачивается под свои мысли. Зачем оно же заточенное под чужие?
     
     
  • 4.20, Аноним (-), 16:32, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Собственно движок inmemory database это такой сильно специализированный ...

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

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

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

     
  • 4.21, Аноним (-), 17:51, 05/06/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > На них видать и ориентируются.

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

     

  • 1.8, Michael Shigorin (ok), 09:44, 05/06/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > (подобное наблюдается в пакетах PostgreSQL 9.1 и 9.0 с SSL в Debian и Ubuntu)

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру