forum.opennet.ru - "Обновление PostgreSQL с устранением уязвимости" (28)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Обновление PostgreSQL с устранением уязвимости"	+/–
Сообщение от opennews (?), 12-Авг-21, 20:28
Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 13.4, 12.8, 11.13, 10.18 и 9.6.23. Обновления для ветки 9.6 будут формироваться до ноября 2021 года, 10 - до ноября 2022 года, 11 - до ноября 2023 года, 12 - до ноября 2024 года, 13 до ноября 2025 года... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55629
Ответить \| Правка \| Cообщить модератору

Оглавление

Скрыто модератором, Postgres всё (?), 20:28 , 12-Авг-21, (1) –6

Скрыто модератором, Истина в последней инстанции (?), 20:32 , 12-Авг-21, (2) +2

Скрыто модератором, Укуренные прикрываясь дырой (?), 21:04 , 12-Авг-21, (3) –1

Скрыто модератором, Аноним (4), 21:06 , 12-Авг-21, (4) –1

Это просто показывает что даже такие боги программирования которые пишут Postgre, Аноним (6), 21:09 , 12-Авг-21, (6) +4

Со скулите, где тестов больше кода, вышло забавнее , Аноним (8), 00:38 , 13-Авг-21, (8) –1

Что такое скулите , Аноньимъ (ok), 00:59 , 13-Авг-21, (9)

я имел в виду скулите3, Аноним (8), 01:04 , 13-Авг-21, (10)
sqlite3, supp (?), 01:05 , 13-Авг-21, (11)

А точно боги его пишут А то архитектурных дыр там пока хватает Начиная от спос, Прохожий (??), 01:18 , 13-Авг-21, (12) –2

А как должен удалять записи версионник , edo (ok), 08:00 , 13-Авг-21, (16) –1

Не хранить версии прямо в таблице, например , ДБА (?), 09:51 , 16-Авг-21, (29)

поясните свою мысль, edo (ok), 10:03 , 16-Авг-21, (30)

Если хранить старые версии строк или то, что нужно для их восстановления не вп, ДБА (?), 12:45 , 16-Авг-21, (31)

отлично а как мы узнаем какие из них старые я так понимаю, вы предлагаете подход, edo (ok), 03:07 , 17-Авг-21, (32)

Честно говоря, не в курсе, как там в InnoDB Мне нравится, как в Оракле в табли, ДБА (?), 10:13 , 17-Авг-21, (33)

ну да, оно самое в постгресе называется zheap и вяло пилится уже несколько лет , edo (ok), 11:31 , 17-Авг-21, (34)

direct io не нужно, Catwoolfii (ok), 08:17 , 13-Авг-21, (17) +5

lol Почему же не нужен Зачем двойное кеширование и кривая работа линухового кеш, Ananist (?), 11:40 , 13-Авг-21, (18) –4

Для некоторых рабочих нагрузок DIRECT_IO может оказаться не оптимальным https , Catwoolfii (ok), 13:35 , 13-Авг-21, (19) +2
Всё немножко наоборот DIO - это костыль, необходимый в случаях, когда логика юз, Аноним (21), 13:54 , 13-Авг-21, (21)

Кеширование гарантирует сохранность данных Зачем тогда большинство баз работает, Ananist (?), 17:16 , 13-Авг-21, (25) –1

Очень хороший вопрос В некоторых СУБД не будем показывать пальцем все свежий и, Аноним (21), 14:03 , 14-Авг-21, (27)

Если вы про VACUUM FULL, то это вполне типичный вариант для больших объемов данн, Аноним (21), 14:02 , 13-Авг-21, (23) +1

Это просто показывает что даже такие боги программирования которые пишут Postgre, Bek (??), 06:18 , 13-Авг-21, (15) –1

Самая популярная РСУБД на данный момент, поэтому молодцы что багфиксят, Хан (?), 01:20 , 13-Авг-21, (13) –2
long live, mongo, лютый жжжжж (?), 13:34 , 14-Авг-21, (26)
У растоманов печот что не на расте, Аноним (28), 13:49 , 15-Авг-21, (28)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Postgres всё (?), 12-Авг-21, 20:28 –6 +/–

>специально оформленного запроса прочитать содержимое памяти
ага!
не буду оригинальным: следует переписать на Dlang!

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от Истина в последней инстанции (?), 12-Авг-21, 20:32 +2 +/–

Не будешь. Переписывальщик.
Сейчас ещё укуренные подоспеют со своим растом, когда у самих дыра на дыре и дырой прикрывая.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Укуренные прикрываясь дырой (?), 12-Авг-21, 21:04 –1 +/–

- Переписать на раст! Переписать на раст! Легализовать раст во всех штатах!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #4

4. Сообщение от Аноним (4), 12-Авг-21, 21:06 –1 +/–

На пэхэпэ переписать

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от Аноним (6), 12-Авг-21, 21:09 +4 +/–

Это просто показывает что даже такие боги программирования которые пишут PostgreSQL раз в год, но все равно не могут в память. Щито поделаешь...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #12, #15

8. Сообщение от Аноним (8), 13-Авг-21, 00:38 –1 +/–

Со скулите, где тестов больше кода, вышло забавнее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #9

9. Сообщение от Аноньимъ (ok), 13-Авг-21, 00:59 +/–

Что такое скулите?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10, #11

10. Сообщение от Аноним (8), 13-Авг-21, 01:04 +/–

> Что такое скулите?
я имел в виду скулите3

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

11. Сообщение от supp (?), 13-Авг-21, 01:05 +/–

sqlite3

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

12. Сообщение от Прохожий (??), 13-Авг-21, 01:18 –2 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #16, #17, #23

13. Сообщение от Хан (?), 13-Авг-21, 01:20 –2 +/–

Самая популярная РСУБД на данный момент, поэтому молодцы что багфиксят

Ответить | Правка | Наверх | Cообщить модератору

15. Сообщение от Bek (??), 13-Авг-21, 06:18 –1 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

16. Сообщение от edo (ok), 13-Авг-21, 08:00 –1 +/–

А как должен удалять записи версионник?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #29

17. Сообщение от Catwoolfii (ok), 13-Авг-21, 08:17 +5 +/–

direct io не нужно

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18

18. Сообщение от Ananist (?), 13-Авг-21, 11:40 –4 +/–

lol Почему же не нужен? Зачем двойное кеширование и кривая работа линухового кеша?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #19, #21

19. Сообщение от Catwoolfii (ok), 13-Авг-21, 13:35 +2 +/–

Для некоторых рабочих нагрузок DIRECT_IO может оказаться не оптимальным: https://www.percona.com/blog/2013/01/03/is-there-a-room-for-.../

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

21. Сообщение от Аноним (21), 13-Авг-21, 13:54 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #25

23. Сообщение от Аноним (21), 13-Авг-21, 14:02 +1 +/–

> А то архитектурных дыр там пока хватает. Начиная от способа удаления записей с последующей очисткой,
Если вы про VACUUM FULL, то это вполне типичный вариант для больших объемов данных, когда после каждого чиха не начинается фоновое переписывание таблицы.
> и заканчивая отсутствием direct io.
Direct IO - затычка для ситуаций, когда кэширование создает проблемы с производительностью. А чтобы это произошло, нужно _очень_ извр^Wнетрадиционно использовать кэш. Монти, впрочем, смог.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

25. Сообщение от Ananist (?), 13-Авг-21, 17:16 –1 +/–

Кеширование гарантирует сохранность данных? Зачем тогда большинство баз работает через DIO? Кеш никогда не является блокером? Может он не вымещается, по случайному скану?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27

26. Сообщение от лютый жжжжж (?), 14-Авг-21, 13:34 +/–

long live, mongo

Ответить | Правка | Наверх | Cообщить модератору

27. Сообщение от Аноним (21), 14-Авг-21, 14:03 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

28. Сообщение от Аноним (28), 15-Авг-21, 13:49 +/–

У растоманов печот что не на расте

Ответить | Правка | Наверх | Cообщить модератору

29. Сообщение от ДБА (?), 16-Авг-21, 09:51 +/–

Не хранить версии прямо в таблице, например?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #30

30. Сообщение от edo (ok), 16-Авг-21, 10:03 +/–

> Не хранить версии прямо в таблице, например?
поясните свою мысль

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #31

31. Сообщение от ДБА (?), 16-Авг-21, 12:45 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #32

32. Сообщение от edo (ok), 17-Авг-21, 03:07 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #33

33. Сообщение от ДБА (?), 17-Авг-21, 10:13 +/–

Честно говоря, не в курсе, как там в InnoDB. Мне нравится, как в Оракле: в табличный тейблспейс пишется только актуальная версия строки. При изменении она же и обновляется. Для каждого вектора изменений пишется запись отмены изменений (undo), которая циклично пишется в отдельный undo tablespace (или, в далёком прошлом, rollback segment). При необходимости достать старую версию строки, берём текущую и последовательно накатываем на неё undo до нужного состояния. И никакого мусора.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #34

34. Сообщение от edo (ok), 17-Авг-21, 11:31 +/–

> Честно говоря, не в курсе, как там в InnoDB. Мне нравится, как
> в Оракле: в табличный тейблспейс пишется только актуальная версия строки. При
> изменении она же и обновляется. Для каждого вектора изменений пишется запись
> отмены изменений (undo), которая циклично пишется в отдельный undo tablespace (или,
> в далёком прошлом, rollback segment). При необходимости достать старую версию строки,
> берём текущую и последовательно накатываем на неё undo до нужного состояния.
> И никакого мусора.
ну да, оно самое.
в постгресе называется zheap и вяло пилится уже несколько лет. ЕМНИП update быстрее, delete немного медленнее; в сумме быстрее, но не сказать, что разница критичная.
насколько я понимаю, в ближайшее время ожидать не стоит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от Postgres всё (?), 12-Авг-21, 20:28	–6 +/–
>специально оформленного запроса прочитать содержимое памяти ага! не буду оригинальным: следует переписать на Dlang!
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2

2. Сообщение от Истина в последней инстанции (?), 12-Авг-21, 20:32	+2 +/–
Не будешь. Переписывальщик. Сейчас ещё укуренные подоспеют со своим растом, когда у самих дыра на дыре и дырой прикрывая.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Укуренные прикрываясь дырой (?), 12-Авг-21, 21:04	–1 +/–
- Переписать на раст! Переписать на раст! Легализовать раст во всех штатах!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #4

4. Сообщение от Аноним (4), 12-Авг-21, 21:06	–1 +/–
На пэхэпэ переписать
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3

6. Сообщение от Аноним (6), 12-Авг-21, 21:09	+4 +/–
Это просто показывает что даже такие боги программирования которые пишут PostgreSQL раз в год, но все равно не могут в память. Щито поделаешь...
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #8, #12, #15

8. Сообщение от Аноним (8), 13-Авг-21, 00:38	–1 +/–
Со скулите, где тестов больше кода, вышло забавнее.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #9

9. Сообщение от Аноньимъ (ok), 13-Авг-21, 00:59	+/–
Что такое скулите?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #10, #11

10. Сообщение от Аноним (8), 13-Авг-21, 01:04	+/–
> Что такое скулите? я имел в виду скулите3
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

11. Сообщение от supp (?), 13-Авг-21, 01:05	+/–
sqlite3
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

12. Сообщение от Прохожий (??), 13-Авг-21, 01:18	–2 +/–
А точно боги его пишут? А то архитектурных дыр там пока хватает. Начиная от способа удаления записей с последующей очисткой, и заканчивая отсутствием direct io.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #16, #17, #23

13. Сообщение от Хан (?), 13-Авг-21, 01:20	–2 +/–
Самая популярная РСУБД на данный момент, поэтому молодцы что багфиксят
Ответить \| Правка \| Наверх \| Cообщить модератору

15. Сообщение от Bek (??), 13-Авг-21, 06:18	–1 +/–
Это просто показывает что даже такие боги программирования которые пишут PostgreSQL раз в год, но все равно не могут в память Потому му что есть околодебилы которые архитектора потерли и побежали вверх по донатам , это все последствия не внимательности что архитектор хоть и не кодер программист , но и не последний человек
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

16. Сообщение от edo (ok), 13-Авг-21, 08:00	–1 +/–
А как должен удалять записи версионник?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #29

17. Сообщение от Catwoolfii (ok), 13-Авг-21, 08:17	+5 +/–
direct io не нужно
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #18

18. Сообщение от Ananist (?), 13-Авг-21, 11:40	–4 +/–
lol Почему же не нужен? Зачем двойное кеширование и кривая работа линухового кеша?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #19, #21

19. Сообщение от Catwoolfii (ok), 13-Авг-21, 13:35	+2 +/–
Для некоторых рабочих нагрузок DIRECT_IO может оказаться не оптимальным: https://www.percona.com/blog/2013/01/03/is-there-a-room-for-.../
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18

21. Сообщение от Аноним (21), 13-Авг-21, 13:54	+/–
> lol Почему же не нужен? Зачем двойное кеширование и кривая работа линухового кеша? Всё немножко наоборот. DIO - это костыль, необходимый в случаях, когда логика юзерспейса плохо стыкуется с логикой кэширования ФС. У постгреса такой архитектурной проблемы нет.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18 Ответы: #25

23. Сообщение от Аноним (21), 13-Авг-21, 14:02	+1 +/–
> А то архитектурных дыр там пока хватает. Начиная от способа удаления записей с последующей очисткой, Если вы про VACUUM FULL, то это вполне типичный вариант для больших объемов данных, когда после каждого чиха не начинается фоновое переписывание таблицы. > и заканчивая отсутствием direct io. Direct IO - затычка для ситуаций, когда кэширование создает проблемы с производительностью. А чтобы это произошло, нужно _очень_ извр^Wнетрадиционно использовать кэш. Монти, впрочем, смог.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

25. Сообщение от Ananist (?), 13-Авг-21, 17:16	–1 +/–
Кеширование гарантирует сохранность данных? Зачем тогда большинство баз работает через DIO? Кеш никогда не является блокером? Может он не вымещается, по случайному скану?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #21 Ответы: #27

26. Сообщение от лютый жжжжж (?), 14-Авг-21, 13:34	+/–
long live, mongo
Ответить \| Правка \| Наверх \| Cообщить модератору

27. Сообщение от Аноним (21), 14-Авг-21, 14:03	+/–
> Кеширование гарантирует сохранность данных? Зачем тогда большинство баз работает через DIO? Очень хороший вопрос. В некоторых СУБД (не будем показывать пальцем) все свежий изменения текущего состояния собраны в одном файле, и для фиксации изменений на диск достаточно одного вызова fsync(). В других СУБД (опять-таки, не будем показывать пальцем) отличия записанного состояния от текущего разбросаны по множеству файлов, причем некоторые из них могут быть очень большими. Тут уже, если хочется мало-мальски надёжно, без костылей direct io никак.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #25

28. Сообщение от Аноним (28), 15-Авг-21, 13:49	+/–
У растоманов печот что не на расте
Ответить \| Правка \| Наверх \| Cообщить модератору

29. Сообщение от ДБА (?), 16-Авг-21, 09:51	+/–
Не хранить версии прямо в таблице, например?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #30

30. Сообщение от edo (ok), 16-Авг-21, 10:03	+/–
> Не хранить версии прямо в таблице, например? поясните свою мысль
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #29 Ответы: #31

31. Сообщение от ДБА (?), 16-Авг-21, 12:45	+/–
>> Не хранить версии прямо в таблице, например? > поясните свою мысль Если хранить старые версии строк (или то, что нужно для их восстановления) не вперемешку с таблицей, а, например, в отдельном тейблспейсе, принципиально отпадает необходимость в вакууме.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #30 Ответы: #32

32. Сообщение от edo (ok), 17-Авг-21, 03:07	+/–
>>> Не хранить версии прямо в таблице, например? >> поясните свою мысль > Если хранить старые версии строк (или то, что нужно для их восстановления) > не вперемешку с таблицей, а, например, в отдельном тейблспейсе, принципиально отпадает > необходимость в вакууме. отлично а как мы узнаем какие из них старые? я так понимаю, вы предлагаете подход, подобный используемому в innodb, нельзя сказать, что у него совершенно нет недостатков.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #31 Ответы: #33

33. Сообщение от ДБА (?), 17-Авг-21, 10:13	+/–
Честно говоря, не в курсе, как там в InnoDB. Мне нравится, как в Оракле: в табличный тейблспейс пишется только актуальная версия строки. При изменении она же и обновляется. Для каждого вектора изменений пишется запись отмены изменений (undo), которая циклично пишется в отдельный undo tablespace (или, в далёком прошлом, rollback segment). При необходимости достать старую версию строки, берём текущую и последовательно накатываем на неё undo до нужного состояния. И никакого мусора.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #32 Ответы: #34

34. Сообщение от edo (ok), 17-Авг-21, 11:31	+/–
> Честно говоря, не в курсе, как там в InnoDB. Мне нравится, как > в Оракле: в табличный тейблспейс пишется только актуальная версия строки. При > изменении она же и обновляется. Для каждого вектора изменений пишется запись > отмены изменений (undo), которая циклично пишется в отдельный undo tablespace (или, > в далёком прошлом, rollback segment). При необходимости достать старую версию строки, > берём текущую и последовательно накатываем на неё undo до нужного состояния. > И никакого мусора. ну да, оно самое. в постгресе называется zheap и вяло пилится уже несколько лет. ЕМНИП update быстрее, delete немного медленнее; в сумме быстрее, но не сказать, что разница критичная. насколько я понимаю, в ближайшее время ожидать не стоит.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #33