The OpenNET Project / Index page

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

Обновление PostgreSQL с устранением уязвимости

12.08.2021 20:06

Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 13.4, 12.8, 11.13, 10.18 и 9.6.23. Обновления для ветки 9.6 будут формироваться до ноября 2021 года, 10 - до ноября 2022 года, 11 - до ноября 2023 года, 12 - до ноября 2024 года, 13 до ноября 2025 года.

В новых версиях предложено 75 исправлений и устранена уязвимость CVE-2021-3677, позволяющая через выполнение специально оформленного запроса прочитать содержимое памяти серверного процесса. Атака может быть совершена любым пользователем, имеющим доступ для выполнения SQL-запросов. Проблеме подвержены только ветки PostgreSQL 11, 12 и 13. Известные варианты атак не затрагивают конфигурации с настройкой max_worker_processes=0, но не исключено существование вариантов, не зависящих от этой настройки.

  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: PostgreSQL Anonymizer 0.6, расширение для анонимизации данных в СУБД
  3. OpenNews: Компания Alibaba открыла код распределённой СУБД PolarDB, основанной на PostgreSQL
  4. OpenNews: Опубликован Kubegres, инструментарий для развёртывания кластера PostgreSQL
  5. OpenNews: Релиз СУБД PostgreSQL 13
  6. OpenNews: Для PostgreSQL подготовлено дополнение AGE для хранения данных в форме графа
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/55629-postgresql
Ключевые слова: postgresql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Postgres всё (?), 20:28, 12/08/2021 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –6 +/
     

     ....ответы скрыты (3)

  • 1.6, Аноним (6), 21:09, 12/08/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Это просто показывает что даже такие боги программирования которые пишут PostgreSQL раз в год, но все равно не могут в память. Щито поделаешь...
     
     
  • 2.8, Аноним (8), 00:38, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Со скулите, где тестов больше кода, вышло забавнее.
     
     
  • 3.9, Аноньимъ (ok), 00:59, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Что такое скулите?
     
     
  • 4.10, Аноним (8), 01:04, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Что такое скулите?

    я имел в виду скулите3

     
  • 4.11, supp (?), 01:05, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    sqlite3
     
  • 2.12, Прохожий (??), 01:18, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А точно боги его пишут? А то архитектурных дыр там пока хватает. Начиная от способа удаления записей с последующей очисткой, и заканчивая отсутствием direct io.
     
     
  • 3.16, edo (ok), 08:00, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А как должен удалять записи версионник?
     
     
  • 4.29, ДБА (?), 09:51, 16/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не хранить версии прямо в таблице, например?
     
     
  • 5.30, edo (ok), 10:03, 16/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Не хранить версии прямо в таблице, например?

    поясните свою мысль

     
     
  • 6.31, ДБА (?), 12:45, 16/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> Не хранить версии прямо в таблице, например?
    > поясните свою мысль

    Если хранить старые версии строк (или то, что нужно для их восстановления) не вперемешку с таблицей, а, например, в отдельном тейблспейсе, принципиально отпадает необходимость в вакууме.

     
     
  • 7.32, edo (ok), 03:07, 17/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Не хранить версии прямо в таблице, например?
    >> поясните свою мысль
    > Если хранить старые версии строк (или то, что нужно для их восстановления)
    > не вперемешку с таблицей, а, например, в отдельном тейблспейсе, принципиально отпадает
    > необходимость в вакууме.

    отлично а как мы узнаем какие из них старые?
    я так понимаю, вы предлагаете подход, подобный используемому в innodb, нельзя сказать, что у него совершенно нет недостатков.

     
     
  • 8.33, ДБА (?), 10:13, 17/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Честно говоря, не в курсе, как там в InnoDB Мне нравится, как в Оракле в табли... текст свёрнут, показать
     
     
  • 9.34, edo (ok), 11:31, 17/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    ну да, оно самое в постгресе называется zheap и вяло пилится уже несколько лет ... текст свёрнут, показать
     
  • 3.17, Catwoolfii (ok), 08:17, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • +5 +/
    direct io не нужно
     
     
  • 4.18, Ananist (?), 11:40, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • –4 +/
    lol Почему же не нужен? Зачем двойное кеширование и кривая работа линухового кеша?
     
     
  • 5.19, Catwoolfii (ok), 13:35, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Для некоторых рабочих нагрузок DIRECT_IO может оказаться не оптимальным: https://www.percona.com/blog/2013/01/03/is-there-a-room-for-more-mysql-io-opti
     
  • 5.21, Аноним (21), 13:54, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >  lol Почему же не нужен? Зачем двойное кеширование и кривая работа линухового кеша?

    Всё немножко наоборот. DIO - это костыль, необходимый в случаях, когда логика юзерспейса плохо стыкуется с логикой кэширования ФС.
    У постгреса такой архитектурной проблемы нет.

     
     
  • 6.25, Ananist (?), 17:16, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кеширование гарантирует сохранность данных? Зачем тогда большинство баз работает через DIO? Кеш никогда не является блокером? Может он не вымещается, по случайному скану?
     
     
  • 7.27, Аноним (21), 14:03, 14/08/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Кеширование гарантирует сохранность данных? Зачем тогда большинство баз работает через DIO?

    Очень хороший вопрос.
    В некоторых СУБД (не будем показывать пальцем) все свежий изменения текущего состояния собраны в одном файле, и для фиксации изменений на диск достаточно одного вызова fsync().
    В других СУБД (опять-таки, не будем показывать пальцем) отличия записанного состояния от текущего разбросаны по множеству файлов, причем некоторые из них могут быть очень большими. Тут уже, если хочется мало-мальски надёжно, без костылей direct io никак.

     
  • 3.23, Аноним (21), 14:02, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А то архитектурных дыр там пока хватает. Начиная от способа удаления записей с последующей очисткой,

    Если вы про VACUUM FULL, то это вполне типичный вариант для больших объемов данных, когда после каждого чиха не начинается фоновое переписывание таблицы.

    > и заканчивая отсутствием direct io.

    Direct IO - затычка для ситуаций, когда кэширование создает проблемы с производительностью. А чтобы это произошло, нужно _очень_ извр^Wнетрадиционно использовать кэш. Монти, впрочем, смог.

     
  • 2.15, Bek (??), 06:18, 13/08/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это просто показывает что даже такие боги программирования которые пишут PostgreSQL раз в год, но все равно не могут в память

    Потому му что есть околодебилы которые архитектора потерли и побежали вверх по донатам , это все последствия не внимательности что архитектор хоть и не кодер программист , но и не последний человек

     

  • 1.13, Хан (?), 01:20, 13/08/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Самая популярная РСУБД на данный момент, поэтому молодцы что багфиксят
     
  • 1.26, лютый жжжжж (?), 13:34, 14/08/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    long live, mongo
     
  • 1.28, Аноним (28), 13:49, 15/08/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У растоманов печот что не на расте
     

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



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

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