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

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

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

"Обновление PostgreSQL с устранением уязвимостей"	+/–
Сообщение от opennews (??), 14-Ноя-20, 11:25
Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL: 13.1, 12.5, 11.10, 10.15, 9.6.20 и 9.5.24. Обновления для ветки 9.5 будут формироваться до февраля 2021 г., 9.6 - до ноября 2021 года, 10 - до ноября 2022 года, 11 - до ноября 2023 года, 12 - до ноября 2024 года, 13 до ноября 2025 года... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54088
Ответить \| Правка \| Cообщить модератору

Оглавление

Патченный слоник - хороший слоник , InuYasha (??), 11:25 , 14-Ноя-20, (1) +6
Скрыто модератором, Аноним (2), 11:36 , 14-Ноя-20, (2) –33

Скрыто модератором, Иваня (?), 12:00 , 14-Ноя-20, (3) +4
Скрыто модератором, zo0M (ok), 12:02 , 14-Ноя-20, (4) +6
Скрыто модератором, Catwoolfii (ok), 12:41 , 14-Ноя-20, (6) +3

Скрыто модератором, Lex (??), 12:48 , 14-Ноя-20, (8) +3
Скрыто модератором, Аноним (2), 13:06 , 14-Ноя-20, (10) –7

Скрыто модератором, Catwoolfii (ok), 13:30 , 14-Ноя-20, (13) +1

Скрыто модератором, And (??), 14:07 , 14-Ноя-20, (18)

Скрыто модератором, Аноним (15), 13:53 , 14-Ноя-20, (15) +2

Скрыто модератором, Lex (??), 14:34 , 14-Ноя-20, (20) –1
Скрыто модератором, пох. (?), 22:24 , 14-Ноя-20, (30)

13 как падала на создании GIST индексов по триграмам, так и 13 1 ровно в том же , Анонимленьлогиниться (?), 12:37 , 14-Ноя-20, (5) +4

Число нехорошее, по-видимому 124 , Аноним (7), 12:46 , 14-Ноя-20, (7)
А багу зарегали , Аанон (?), 12:50 , 14-Ноя-20, (9) +2

Нет Как ни пытался, не смог сделать минимальное воспроизведение - т е оно не з, Анонимленьлогиниться (?), 19:54 , 14-Ноя-20, (26) +2

А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при паден, мяя (?), 23:40 , 14-Ноя-20, (31)

Есть, равно как и понимание что без отладочной инфы а почему-то в pgdg стали со, Анонимленьлогиниться (?), 00:30 , 15-Ноя-20, (34)

В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно, Аноним (35), 00:58 , 15-Ноя-20, (35) +2

Это в редхате Да, они раньше паковали debuginfo К 9 например но почему-то к, Анонимленьлогиниться (?), 18:02 , 15-Ноя-20, (43)

Devrim сопровождающий rpm репы решил в отдельный репозиторий вынести https y, Мелкий (?), 18:40 , 16-Ноя-20, (46)

Это тут не причем, ноМало собрать debuginfo Надо собрать их к нужным пакетам , Анонимленьлогиниться (?), 23:46 , 17-Ноя-20, (48)

gt оверквотинг удален Ох Посыпаю голову пеплом я понял, в чем проблема Деб, Анонимленьлогиниться (?), 00:03 , 18-Ноя-20, (51)
Ну, к rpm репе действительно есть вопросы А даже вот такой backtrace на самом , Мелкий (?), 00:11 , 18-Ноя-20, (52)

http apt postgresql org pub repos apt pool main p postgresql-13 postgresql-13-, тральшик (?), 07:33 , 16-Ноя-20, (45)

нет Оно оказалось тут https download postgresql org pub repos yum debug 13 re, Анонимленьлогиниться (?), 23:48 , 17-Ноя-20, (49)

сообщите хотяб в таком виде, возможно, вам там напишут или волшебные флаги или с, JL2001 (ok), 00:16 , 15-Ноя-20, (33)

a self-compiled Postgres 12 1I could successfully running a default-configur, Anon_noXX (?), 04:47 , 15-Ноя-20, (36)

Впрочем, я погорячился, товарищи из Core Team проблему подтверждают Сорри , Anon_noXX (?), 04:54 , 15-Ноя-20, (37)

И опять я не прав, переписка-то 2019 годом заканчивается , Anon_noXX (?), 04:57 , 15-Ноя-20, (38)

так ворвитесь в тред и апните топикможет у них не на ком воспроизвестизы а вы п, JL2001 (ok), 15:36 , 15-Ноя-20, (41)

Да нет Там бага была другая совсем Кто-то доопотимизировался при записи WAL в , Анонимленьлогиниться (?), 18:01 , 15-Ноя-20, (42) +1

номер репорта есть , Аноним (19), 14:33 , 14-Ноя-20, (19) +2
Обратитесь к Олегу Бартунову Это один из ключевых разработчиков Он обязательно, DEF (?), 20:53 , 17-Ноя-20, (47)

Спасибо Уже кто-то зарепортил аналогичный баг см комментарий выше и сделали , Анонимленьлогиниться (?), 23:49 , 17-Ноя-20, (50)

Почему не в одном хостинге я не видел САБЖ Один лишь MySQL, прямо какой-то заго, Аноним (2), 13:10 , 14-Ноя-20, (11) –6

Потому что сабж плохо управляем в целом, да и производительность из-за постоянно, Аноним (12), 13:28 , 14-Ноя-20, (12) –9

это было до 8 1, когда не было автовакуума сейчас все пучком даже на больших на, Аноним (19), 15:24 , 14-Ноя-20, (21) +1

Не заговор, а не востребован , Аноним (14), 13:38 , 14-Ноя-20, (14) –4
Потому что хостинг - это самый дешевый вариант, для сайтов с крайне малой нагруз, Аноним (15), 13:55 , 14-Ноя-20, (16) +3

VPS из той же ниши, что и хостинг Серьезную нагрузку не тянет, а если загрузить, BSA (?), 15:57 , 14-Ноя-20, (22)

В случае с ДО там топовые конфигурации получали значительно больше ресурсов и ме, Аноним (28), 21:34 , 14-Ноя-20, (28)
бред у хетцнеров даже самый просто vps за 3 евро просто реактивный, что по проц, лютый жабби__ (?), 21:36 , 14-Ноя-20, (29) +1

Например У меня ровно наоборот Забыл когда последний раз видел mysql mariadb , Иван (??), 13:56 , 14-Ноя-20, (17) +2
Что вы имеете в виду под хостингом AWS - постгрес есть Google Cloud - постгрес , Аноним (24), 17:24 , 14-Ноя-20, (24) +3

Если раньше под сайт достаточно было виртуального хоста фтп MySQL, то теперь, Аноним (44), 23:42 , 15-Ноя-20, (44) +1

Потому что мамкины вебмастера не умеют в что-то сложнее SELECT FROM , zzz (??), 18:01 , 14-Ноя-20, (25) –1
Gitlab, например, только с postgresql работает, Casm (??), 20:33 , 14-Ноя-20, (27)
Если MySQL достаточно, то почему бы и нет А вот для DW MySQL мало пригоден, тогд, ptr128 (?), 15:33 , 21-Ноя-20, (53)

Оказывается VACUUM теперь не только к тормознутости приводит сам git-подобный д, Ilya Indigo (ok), 16:25 , 14-Ноя-20, (23) –8

Работает не трожь, Аноним (40), 15:13 , 15-Ноя-20, (40) +2

Скрыто модератором, Аноним (40), 15:10 , 15-Ноя-20, (39) –3

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

1. Сообщение от InuYasha (??), 14-Ноя-20, 11:25 +6 +/–

Патченный слоник - хороший слоник.

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

2. Сообщение от Аноним (2), 14-Ноя-20, 11:36 –33 +/–

Решетo, а вообще везде MySQL стандарт.

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

3. Сообщение от Иваня (?), 14-Ноя-20, 12:00 +4 +/–

MySQL тож решэто :(

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

4. Сообщение от zo0M (ok), 14-Ноя-20, 12:02 +6 +/–

толсто

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

5. Сообщение от Анонимленьлогиниться (?), 14-Ноя-20, 12:37 +4 +/–

13 как падала на создании GIST индексов по триграмам, так и 13.1 ровно в том же месте падает :-(
Остаемся на 12, она стабильная..

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #9, #19, #47

6. Сообщение от Catwoolfii (ok), 14-Ноя-20, 12:41 +3 +/–

для простых сайтиков - да, стандарт

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

7. Сообщение от Аноним (7), 14-Ноя-20, 12:46 +/–

Число нехорошее, по-видимому :|

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

8. Сообщение от Lex (??), 14-Ноя-20, 12:48 +3 +/–

С ростом доли SSD в хостинге, для простых сайтов стандартом вновь может стать SQLite

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

9. Сообщение от Аанон (?), 14-Ноя-20, 12:50 +2 +/–

А багу зарегали?

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

10. Сообщение от Аноним (2), 14-Ноя-20, 13:06 –7 +/–

А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг?

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

11. Сообщение от Аноним (2), 14-Ноя-20, 13:10 –6 +/–

Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #14, #16, #17, #24, #25, #27, #53

12. Сообщение от Аноним (12), 14-Ноя-20, 13:28 –9 +/–

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

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

13. Сообщение от Catwoolfii (ok), 14-Ноя-20, 13:30 +1 +/–

Может быть потому, что популярные CMS поддерживают только mysql?

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

14. Сообщение от Аноним (14), 14-Ноя-20, 13:38 –4 +/–

Не заговор, а не востребован.

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

15. Сообщение от Аноним (15), 14-Ноя-20, 13:53 +2 +/–

> А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг?
Наверное, потому что вы работаете только с очень простыми сайтами.
За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин, у которого один покупатель в неделю", MySQL практически не встречается.

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

16. Сообщение от Аноним (15), 14-Ноя-20, 13:55 +3 +/–

> Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор
Потому что хостинг - это самый дешевый вариант, для сайтов с крайне малой нагрузкой.
Что-то более-менее заметное живет на VPS, дедике и колокации.

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

17. Сообщение от Иван (??), 14-Ноя-20, 13:56 +2 +/–

Например?
У меня ровно наоборот. Забыл когда последний раз видел mysql/mariadb.

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

18. Сообщение от And (??), 14-Ноя-20, 14:07 +/–

Хм... Вы где вообще нашли MySql. Maria DB давно уже вместо него. :)
Старый у Вас софт.

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

19. Сообщение от Аноним (19), 14-Ноя-20, 14:33 +2 +/–

номер репорта есть ?

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

20. Сообщение от Lex (??), 14-Ноя-20, 14:34 –1 +/–

Очень даже встречается
Не встречается он, обычно, в конторах( если уж зашла речь о торговле ) с десятками-сотнями-тысячами торговых точек и эпической системой, связывающей все это + закупки + аналитику итп. Но там из реальных вариантов или MSSQL, или Postgres, поскольку базы реально огромны

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

21. Сообщение от Аноним (19), 14-Ноя-20, 15:24 +1 +/–

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

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

22. Сообщение от BSA (?), 14-Ноя-20, 15:57 +/–

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

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

23. Сообщение от Ilya Indigo (ok), 14-Ноя-20, 16:25 –8 +/–

Оказывается VACUUM теперь не только к тормознутости приводит (сам git-подобный движок хранения, которому он нужен), но ещё и к проблеме с безопасностью.

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

24. Сообщение от Аноним (24), 14-Ноя-20, 17:24 +3 +/–

Что вы имеете в виду под хостингом?
AWS - постгрес есть. Google Cloud - постгрес есть. Azure - постгрес есть.  DigitalOcean - постгрес есть. Yandex.Cloud - постгрес есть. Mail.ru cloud solutions - постгрес есть.

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

25. Сообщение от zzz (??), 14-Ноя-20, 18:01 –1 +/–

Потому что мамкины вебмастера не умеют в что-то сложнее SELECT * FROM?

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

26. Сообщение от Анонимленьлогиниться (?), 14-Ноя-20, 19:54 +2 +/–

> А багу зарегали?
Нет. Как ни пытался, не смог сделать минимальное воспроизведение - т.е. оно не зависит от конкретных данных, на таблице 10000 строк падает, на таблице 5000 строк (любая половина этих 10000) - нет. Репорт с реальными данными сделать не могу (да и им нужно предсказуемое воспроизведение).
Нашел только что падает особенно резво при попытке указать fillfactor отличный от дефолтного. Причем с некоторыми падает, с некоторыми нет.
На табличке на 100000 строк падает и без указания fillfactor. Чем больше табличка, тем резвее падает. Падает весь сервер, натурально, без каких-либо внятных сообщений.
Очень надеялся, что в 13.1 что-то станет лучше, но увы. Думаю, мало кто использует gist индексы... В первых релизах 12 (12.0/12.1) тоже было падение на этой же табличке ровно на этом же индексе :)) Но там падало иначе, в wal writer, при этом выводилось некое сообщение об ошибке, в итоге кто-то зарепортил такую же багу (https://www.postgresql.org/message-id/16162-45d21b7b6c1a3105... и начиная с 12.2 исправили и получилось проапгрейдиться на 12.
А вот 13 уже падает главный процесс.. внятной ошибки не выводится.. ждем репортов.

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

27. Сообщение от Casm (??), 14-Ноя-20, 20:33 +/–

Gitlab, например, только с postgresql работает

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

28. Сообщение от Аноним (28), 14-Ноя-20, 21:34 +/–

В случае с ДО там топовые конфигурации получали значительно больше ресурсов и меньше соседей с шиткоинами. Линода вроде меньше оверселлила. Возмущений что-то не припомню, зато помню как в зависимости от поведения соседей менялась производительность.

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

29. Сообщение от лютый жабби__ (?), 14-Ноя-20, 21:36 +1 +/–

>VPS из той же ниши, что и хостинг.
бред. у хетцнеров даже самый просто vps за 3 евро просто реактивный, что по процу, что по IO.
на многих задачах оно просто рвёт парумилионные железные серверы (более старые и без SSD) )

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

30. Сообщение от пох. (?), 14-Ноя-20, 22:24 +/–

> За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин,
> у которого один покупатель в неделю", MySQL практически не встречается.
встречается, встречается - у тех кто в свое время либо наелись "vacuum full; reindex", либо вовремя избежали встречи. Ну и с ha всерьез столкнулись. С травмами.
Другое дело что это тот, второй стул, и ассортимент на нем, за пределами шитхостингов за три копейки, тоже весьма так себе.
За ms или oracle рабовладельцы могут не хотеть платить, sqlite надо уметь готовить, с этим у современных "разработчиков" плохо.

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

31. Сообщение от мяя (?), 14-Ноя-20, 23:40 +/–

А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при падении навыков нет?

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

33. Сообщение от JL2001 (ok), 15-Ноя-20, 00:16 +/–

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

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

34. Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 00:30 +/–

> А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при
> падении навыков нет?
Есть, равно как и понимание что без отладочной инфы (а почему-то в pgdg стали собирать без debuginfo) и потом траты кучи времени на объяснение разработчикам, где как и что реального результата не получится. А это время мне, увы, не оплачивается.. Так что я лучше займусь задачами, которые нужны тому, кто мне платит :)

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

35. Сообщение от Аноним (35), 15-Ноя-20, 00:58 +2 +/–

В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно поставить и у вас появятся отладочные символы в отладчике.

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

36. Сообщение от Anon_noXX (?), 15-Ноя-20, 04:47 +/–

a self-compiled Postgres 12.1
I could successfully ... running a default-configured packaged version of postgres 12 for ubuntu 16.04
Может, оно? А может быть jit? Или ФС - zfs.

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

37. Сообщение от Anon_noXX (?), 15-Ноя-20, 04:54 +/–

Впрочем, я погорячился, товарищи из Core Team проблему подтверждают. Сорри.

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

38. Сообщение от Anon_noXX (?), 15-Ноя-20, 04:57 +/–

И опять я не прав, переписка-то 2019 годом заканчивается :)

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

39. Сообщение от Аноним (40), 15-Ноя-20, 15:10 –3 +/–

К базам просто прикасаться то страшно, а тут еще и обновить. А если все упадет? Лучше уж проприетарщина, там дыры если и есть их сложнее искать.

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

40. Сообщение от Аноним (40), 15-Ноя-20, 15:13 +2 +/–

Работает не трожь

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

41. Сообщение от JL2001 (ok), 15-Ноя-20, 15:36 +/–

> И опять я не прав, переписка-то 2019 годом заканчивается :)
так ворвитесь в тред и апните топик
может у них не на ком воспроизвести
зы: а вы пробовали на копии бд заменить боевые данные рандомными значениями и воспроизвести на этом уже не секретном инстансе?
зыы: после экспорта+импорт чере sql воспроизводится? тоесть не зависит от раскладки данных по секторам?
зыыы: ну и на другую фс точно так же можно попробовать перетащить на какой-нить тестовой машине или вообще через mount loop образа фс, а не на реальной фс

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

42. Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 18:01 +1 +/–

>> И опять я не прав, переписка-то 2019 годом заканчивается :)
> так ворвитесь в тред и апните топик
> может у них не на ком воспроизвести
Да нет! Там бага была другая совсем. Кто-то доопотимизировался при записи WAL в PG12 :) И индекс, работавший в 10 и 11 сломался. Ту багу давно поправили. Просто падало ровно на этом индексе этой же таблицы. Но падало в wal writer; при этом основной процесс постгреса успевал выдать нечто внятное перед полным паднием. А сейчас падает вообще все сразу и без внятной ошибки.
> зы: а вы пробовали на копии бд заменить боевые данные рандомными значениями
> и воспроизвести на этом уже не секретном инстансе?
Это и есть на копии. Это даже не продакшен, я воспроизвожу багу при попытке сделать dump+restore из 12 в 13 на дев или тестовых БД. Более того, дело касается ровно одной таблицы, другие не нужны.
> зыы: после экспорта+импорт чере sql воспроизводится? тоесть не зависит от раскладки данных
> по секторам?
Воспроизводится как угодно. От раскладки не зависит :)
Я могу сделать create table xxx as select * from src_table limit 10000 offset <любое значение>;
И следующий create index test_ind on xxx (gist на (timestamp + text gist_trgm_opts)) на эту новую xxx всегда свалит сервер.
> зыыы: ну и на другую фс точно так же можно попробовать перетащить
> на какой-нить тестовой машине или вообще через mount loop образа фс,
> а не на реальной фс
От этого не зависит.

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

43. Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 18:02 +/–

> В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно
> поставить и у вас появятся отладочные символы в отладчике.
Это в редхате. Да, они раньше паковали debuginfo.. К 9 например.. но почему-то к последним версиям перестали. Видимо, багрепортов больше не ждут.

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

44. Сообщение от Аноним (44), 15-Ноя-20, 23:42 +1 +/–

Если раньше под сайт достаточно было виртуального хоста + фтп + MySQL, то теперь надо отдельная виртуальная машина в облаке с операционкой в докере с постгресом, с операционной в докер с нджинксом, с операционной в докер с питоном, с кубернетесом, что бы запускать этот зоопарк докеров, не забываем про еластик стек, графану, прометеус, что там ещё молодёжно?

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

45. Сообщение от тральшик (?), 16-Ноя-20, 07:33 +/–

http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgres... не оно?

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

46. Сообщение от Мелкий (?), 16-Ноя-20, 18:40 +/–

> Это в редхате. Да, они раньше паковали debuginfo.. К 9 например..
Devrim (сопровождающий rpm репы) решил в отдельный репозиторий вынести https://yum.postgresql.org/news/devel-rpms-require-a-new-rep.../
В deb репозитории на месте. postgresql-12-dbgsym в частности. (какое-то время назад, впрочем, назывались *-dbg вместо dbgsym, возможно вас это запутало)

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

47. Сообщение от DEF (?), 17-Ноя-20, 20:53 +/–

Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет. Его контакты легко гуглятся.

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

48. Сообщение от Анонимленьлогиниться (?), 17-Ноя-20, 23:46 +/–

>> Это в редхате. Да, они раньше паковали debuginfo.. К 9 например..
> Devrim (сопровождающий rpm репы) решил в отдельный репозиторий вынести https://yum.postgresql.org/news/devel-rpms-require-a-new-rep.../
Это тут не причем, но
> В deb репозитории на месте. postgresql-12-dbgsym в частности. (какое-то время назад, впрочем,
> назывались *-dbg вместо dbgsym, возможно вас это запутало)
Мало собрать debuginfo :) Надо собрать их к нужным пакетам! Что мейнтейнеры постгреса сделать не сумели.
warning: the debug information found in "/usr/lib/debug//usr/pgsql-13/lib/pg_trgm.so-13.1-1PGDG.rhel8.x86_64.debug" does not match "/usr/pgsql-13/lib/pg_trgm.so" (CRC mismatch).
Missing separate debuginfo for /usr/pgsql-13/lib/pg_trgm.so
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug

Нужные пакеты, разумеется, стоят:
$ rpm -qf /usr/lib/debug//usr/pgsql-13/lib/pg_trgm.so-13.1-1PGDG.rhel8.x86_64.debug  /usr/pgsql-13/lib/pg_trgm.so
postgresql13-contrib-debuginfo-13.1-1PGDG.rhel8.x86_64
postgresql13-contrib-13.1-1PGDG.rhel8.x86_64
$ dnf debuginfo-install --enablerepo=pgdg13-updates-debuginfo /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
подключение репозитория epel-modular-debuginfo
подключение репозитория epel-debuginfo
Последняя проверка окончания срока действия метаданных: 0:12:07 назад, Вт 17 ноя 2020 15:11:26.
Нет совпадений для аргумента: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
Ошибка: Не удалось найти совпадение: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
опаньки...
А падение как раз в pg_trgm.so. И состояния переменных трейса не получить.. Увы.
Core was generated by `postgres: postgres message_db_dev [local] CREATE INDEX '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:304
304    movq  -8(%rsi,%rdx), %rcx
(gdb) where
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:304
#1  0x00007fbb71fe1d2b in gtrgm_alloc () from /usr/pgsql-13/lib/pg_trgm.so
#2  0x00007fbb71fe328e in gtrgm_picksplit () from /usr/pgsql-13/lib/pg_trgm.so
#3  0x00000000008d1ace in FunctionCall2Coll ()
#4  0x00000000004b174e in gistSplitByKey ()
#5  0x00000000004b1b4f in gistSplitByKey ()
#6  0x00000000004a8dc3 in gistSplit ()
#7  0x00000000004a918b in gistplacetopage ()
#8  0x00000000004a9cb8 in gistinserttuples ()
#9  0x00000000004aa10a in gistdoinsert ()
#10 0x00000000004ab80e in gistBuildCallback ()
#11 0x00000000004ccf0d in heapam_index_build_range_scan ()
#12 0x00000000004abe25 in gistbuild ()
#13 0x0000000000541887 in index_build ()
#14 0x0000000000542da0 in index_create ()
Т.е. gtrgm_alloc делает memmove в неинициализированные области памяти..
Но не все потеряно - я не смог, другие смогли. Очень похожий наконец-то зарепортили в IRC и пять дней назад выкатили патч (я не проверял, но по идее это то, что надо). Вот тут: https://www.postgresql-archive.org/Strange-GiST-logic-leadin...
Жаль, в релиз не вошел. Ну ничего, PG 12 и 12.1 тоже были с критическим багом GIST индексов.. ситуация с 13 просто повторение. Ждем через пол-годика 13.2, работающего немного постабильнее.. Там и проапгрейдимся.
Спасибо всем, кто мотивировал меня таки залезть в трейс. Хоть он и почти пустой из-за кривости рук сборщиков пакетов.

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

49. Сообщение от Анонимленьлогиниться (?), 17-Ноя-20, 23:48 +/–

> http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgres...
> не оно?
нет )
Оно оказалось тут https://download.postgresql.org/pub/repos/yum/debug/13/redha.../
но собрано неправильно и нужный дебагинфо к -contrib пакету не соответствует самому пакету, см. комментарий выше. Ну да ладно.

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

50. Сообщение от Анонимленьлогиниться (?), 17-Ноя-20, 23:49 +/–

> Обратитесь к Олегу Бартунову! Это один из ключевых разработчиков. Он обязательно поможет.
> Его контакты легко гуглятся.
Спасибо. Уже кто-то зарепортил аналогичный баг (см. комментарий выше) и сделали экспериментальный патч.. может в следующем релизе поправят и падать перестанет.

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

51. Сообщение от Анонимленьлогиниться (?), 18-Ноя-20, 00:03 +/–

>[оверквотинг удален]
>  /usr/pgsql-13/lib/pg_trgm.so
> postgresql13-contrib-debuginfo-13.1-1PGDG.rhel8.x86_64
> postgresql13-contrib-13.1-1PGDG.rhel8.x86_64
> $ dnf debuginfo-install --enablerepo=pgdg13-updates-debuginfo /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
> подключение репозитория epel-modular-debuginfo
> подключение репозитория epel-debuginfo
> Последняя проверка окончания срока действия метаданных: 0:12:07 назад, Вт 17 ноя 2020
> 15:11:26.
> Нет совпадений для аргумента: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
> Ошибка: Не удалось найти совпадение: /usr/lib/debug/.build-id/09/0799393b09b0b00e0b95de8ffa9b94fc61d9ad.debug
Ох. Посыпаю голову пеплом.. я понял, в чем проблема. Дебагинфо в теории на месте, но.. все-таки кривые репозитории!
Суть проблемы: postgresql13 для 8.2 и для 8.3 создан с одним номером сборки. Они не обновляют друг друга.. тк они по сути идентичны. Но фактически они разные. На данной системе PG13 был проагпрейжен до 13.1 когда был 8.2, а дебагинфо поставлен когда был 8.3. В репе это разные каталоги с чуть разными, но идентичными версиями сборок. Они идентичны в плане работы, но не идентичны в плане debuginfo. Причем с тем, как сделана их репа, dnf не может увидеть правильный дебагинфо через debuginfo-install, т.к. там фильтр по релизам.
Тому, кто собрал версию для более нового дистрибутива без инкремента чего-либо, на что смотрит rpm, нужно оторвать руки :)

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

52. Сообщение от Мелкий (?), 18-Ноя-20, 00:11 +/–

Ну, к rpm репе действительно есть вопросы...
А даже вот такой backtrace на самом деле уже интересен. gtrgm_alloc сам по себе только в pg13 и появился. Вполне бы уже могли натолкнуть в нужную сторону.
13.2 будет 11 февраля, через полгода 13.3 уже.

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

53. Сообщение от ptr128 (?), 21-Ноя-20, 15:33 +/–

Если MySQL достаточно, то почему бы и нет?
А вот для DW MySQL мало пригоден, тогда как PostgreSQL отлично с многотерабайтными БД справляется. Хоть и не без костылей, как принято в OpenSource )

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

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

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

Партнёры:

Хостинг:

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

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

1. Сообщение от InuYasha (??), 14-Ноя-20, 11:25	+6 +/–
Патченный слоник - хороший слоник.
Ответить \| Правка \| Наверх \| Cообщить модератору

2. Сообщение от Аноним (2), 14-Ноя-20, 11:36	–33 +/–
Решетo, а вообще везде MySQL стандарт.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #3, #4, #6

3. Сообщение от Иваня (?), 14-Ноя-20, 12:00	+4 +/–
MySQL тож решэто :(
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

4. Сообщение от zo0M (ok), 14-Ноя-20, 12:02	+6 +/–
толсто
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

5. Сообщение от Анонимленьлогиниться (?), 14-Ноя-20, 12:37	+4 +/–
13 как падала на создании GIST индексов по триграмам, так и 13.1 ровно в том же месте падает :-( Остаемся на 12, она стабильная..
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #7, #9, #19, #47

6. Сообщение от Catwoolfii (ok), 14-Ноя-20, 12:41	+3 +/–
для простых сайтиков - да, стандарт
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #8, #10

7. Сообщение от Аноним (7), 14-Ноя-20, 12:46	+/–
Число нехорошее, по-видимому :\|
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

8. Сообщение от Lex (??), 14-Ноя-20, 12:48	+3 +/–
С ростом доли SSD в хостинге, для простых сайтов стандартом вновь может стать SQLite
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6

9. Сообщение от Аанон (?), 14-Ноя-20, 12:50	+2 +/–
А багу зарегали?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #26

10. Сообщение от Аноним (2), 14-Ноя-20, 13:06	–7 +/–
А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #13, #15

11. Сообщение от Аноним (2), 14-Ноя-20, 13:10	–6 +/–
Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #12, #14, #16, #17, #24, #25, #27, #53

12. Сообщение от Аноним (12), 14-Ноя-20, 13:28	–9 +/–
Потому что сабж плохо управляем в целом, да и производительность из-за постоянной необходимости вакуума (ну, если не хочешь хранить гигабайты ненужных удалённых строк) у него так себе.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #21

13. Сообщение от Catwoolfii (ok), 14-Ноя-20, 13:30	+1 +/–
Может быть потому, что популярные CMS поддерживают только mysql?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #18

14. Сообщение от Аноним (14), 14-Ноя-20, 13:38	–4 +/–
Не заговор, а не востребован.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

15. Сообщение от Аноним (15), 14-Ноя-20, 13:53	+2 +/–
> А тогда почему не в одном хостинге я не видел ничего отличного от MySQL? Ни SQLite ни Сабж? Может кто подскажет кошерный хостинг? Наверное, потому что вы работаете только с очень простыми сайтами. За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин, у которого один покупатель в неделю", MySQL практически не встречается.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #20, #30

16. Сообщение от Аноним (15), 14-Ноя-20, 13:55	+3 +/–
> Почему не в одном хостинге я не видел САБЖ? Один лишь MySQL, прямо какой-то заговор Потому что хостинг - это самый дешевый вариант, для сайтов с крайне малой нагрузкой. Что-то более-менее заметное живет на VPS, дедике и колокации.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #22

17. Сообщение от Иван (??), 14-Ноя-20, 13:56	+2 +/–
Например? У меня ровно наоборот. Забыл когда последний раз видел mysql/mariadb.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

18. Сообщение от And (??), 14-Ноя-20, 14:07	+/–
Хм... Вы где вообще нашли MySql. Maria DB давно уже вместо него. :) Старый у Вас софт.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13

19. Сообщение от Аноним (19), 14-Ноя-20, 14:33	+2 +/–
номер репорта есть ?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5

20. Сообщение от Lex (??), 14-Ноя-20, 14:34	–1 +/–
Очень даже встречается Не встречается он, обычно, в конторах( если уж зашла речь о торговле ) с десятками-сотнями-тысячами торговых точек и эпической системой, связывающей все это + закупки + аналитику итп. Но там из реальных вариантов или MSSQL, или Postgres, поскольку базы реально огромны
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15

21. Сообщение от Аноним (19), 14-Ноя-20, 15:24	+1 +/–
это было до 8.1, когда не было автовакуума. сейчас все пучком даже на больших нагрузках
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

22. Сообщение от BSA (?), 14-Ноя-20, 15:57	+/–
VPS из той же ниши, что и хостинг. Серьезную нагрузку не тянет, а если загрузить на сколько тянет, то хостер будет возмущаться, что ты слишком много ресурсов потребляешь.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #28, #29

23. Сообщение от Ilya Indigo (ok), 14-Ноя-20, 16:25	–8 +/–
Оказывается VACUUM теперь не только к тормознутости приводит (сам git-подобный движок хранения, которому он нужен), но ещё и к проблеме с безопасностью.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #40

24. Сообщение от Аноним (24), 14-Ноя-20, 17:24	+3 +/–
Что вы имеете в виду под хостингом? AWS - постгрес есть. Google Cloud - постгрес есть. Azure - постгрес есть. DigitalOcean - постгрес есть. Yandex.Cloud - постгрес есть. Mail.ru cloud solutions - постгрес есть.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #44

25. Сообщение от zzz (??), 14-Ноя-20, 18:01	–1 +/–
Потому что мамкины вебмастера не умеют в что-то сложнее SELECT * FROM?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

26. Сообщение от Анонимленьлогиниться (?), 14-Ноя-20, 19:54	+2 +/–
> А багу зарегали? Нет. Как ни пытался, не смог сделать минимальное воспроизведение - т.е. оно не зависит от конкретных данных, на таблице 10000 строк падает, на таблице 5000 строк (любая половина этих 10000) - нет. Репорт с реальными данными сделать не могу (да и им нужно предсказуемое воспроизведение). Нашел только что падает особенно резво при попытке указать fillfactor отличный от дефолтного. Причем с некоторыми падает, с некоторыми нет. На табличке на 100000 строк падает и без указания fillfactor. Чем больше табличка, тем резвее падает. Падает весь сервер, натурально, без каких-либо внятных сообщений. Очень надеялся, что в 13.1 что-то станет лучше, но увы. Думаю, мало кто использует gist индексы... В первых релизах 12 (12.0/12.1) тоже было падение на этой же табличке ровно на этом же индексе :)) Но там падало иначе, в wal writer, при этом выводилось некое сообщение об ошибке, в итоге кто-то зарепортил такую же багу (https://www.postgresql.org/message-id/16162-45d21b7b6c1a3105... и начиная с 12.2 исправили и получилось проапгрейдиться на 12. А вот 13 уже падает главный процесс.. внятной ошибки не выводится.. ждем репортов.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #31, #33

27. Сообщение от Casm (??), 14-Ноя-20, 20:33	+/–
Gitlab, например, только с postgresql работает
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11

28. Сообщение от Аноним (28), 14-Ноя-20, 21:34	+/–
В случае с ДО там топовые конфигурации получали значительно больше ресурсов и меньше соседей с шиткоинами. Линода вроде меньше оверселлила. Возмущений что-то не припомню, зато помню как в зависимости от поведения соседей менялась производительность.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22

29. Сообщение от лютый жабби__ (?), 14-Ноя-20, 21:36	+1 +/–
>VPS из той же ниши, что и хостинг. бред. у хетцнеров даже самый просто vps за 3 евро просто реактивный, что по процу, что по IO. на многих задачах оно просто рвёт парумилионные железные серверы (более старые и без SSD) )
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22

30. Сообщение от пох. (?), 14-Ноя-20, 22:24	+/–
> За пределами ниши "домашняя страничка Васи, для которой хватило бы и статики" и "типа магазин, > у которого один покупатель в неделю", MySQL практически не встречается. встречается, встречается - у тех кто в свое время либо наелись "vacuum full; reindex", либо вовремя избежали встречи. Ну и с ha всерьез столкнулись. С травмами. Другое дело что это тот, второй стул, и ассортимент на нем, за пределами шитхостингов за три копейки, тоже весьма так себе. За ms или oracle рабовладельцы могут не хотеть платить, sqlite надо уметь готовить, с этим у современных "разработчиков" плохо.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15