forum.opennet.ru

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

Оглавление

Обновление PostgreSQL с устранением уязвимостей, opennews (??), 14-Ноя-20, (0) [смотреть все]

Патченный слоник - хороший слоник , 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]

9. "Обновление PostgreSQL с устранением уязвимостей" +2 +/–

Сообщение от Аанон (?), 14-Ноя-20, 12:50

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

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

26. "Обновление PostgreSQL с устранением уязвимостей" +2 +/–

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

> А багу зарегали?
Нет. Как ни пытался, не смог сделать минимальное воспроизведение - т.е. оно не зависит от конкретных данных, на таблице 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ообщить модератору

31. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

34. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

35. "Обновление PostgreSQL с устранением уязвимостей" +2 +/–

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

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

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

43. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

46. "Обновление PostgreSQL с устранением уязвимостей" +/–

Сообщение от Мелкий (?), 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ообщить модератору

48. "Обновление PostgreSQL с устранением уязвимостей" +/–

Сообщение от Анонимленьлогиниться (?), 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ообщить модератору

51. "Обновление PostgreSQL с устранением уязвимостей" +/–

Сообщение от Анонимленьлогиниться (?), 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ообщить модератору

52. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

45. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

49. "Обновление PostgreSQL с устранением уязвимостей" +/–

Сообщение от Анонимленьлогиниться (?), 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ообщить модератору

33. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

36. "Обновление PostgreSQL с устранением уязвимостей" +/–

Сообщение от 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ообщить модератору

37. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

38. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

41. "Обновление PostgreSQL с устранением уязвимостей" +/–

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

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

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

42. "Обновление PostgreSQL с устранением уязвимостей" +1 +/–

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

>> И опять я не прав, переписка-то 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ообщить модератору

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

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

Партнёры:

Хостинг:

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

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


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


	26. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Анонимленьлогиниться (?), 14-Ноя-20, 19:54
	> А багу зарегали? Нет. Как ни пытался, не смог сделать минимальное воспроизведение - т.е. оно не зависит от конкретных данных, на таблице 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ообщить модератору


	31. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от мяя (?), 14-Ноя-20, 23:40
	А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при падении навыков нет?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 00:30
	> А отладчиком к процессу подключиться и получить стек вызовов с ошибкой при > падении навыков нет? Есть, равно как и понимание что без отладочной инфы (а почему-то в pgdg стали собирать без debuginfo) и потом траты кучи времени на объяснение разработчикам, где как и что реального результата не получится. А это время мне, увы, не оплачивается.. Так что я лучше займусь задачами, которые нужны тому, кто мне платит :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Обновление PostgreSQL с устранением уязвимостей"	+2 +/–
	Сообщение от Аноним (35), 15-Ноя-20, 00:58
	В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно поставить и у вас появятся отладочные символы в отладчике.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 18:02
	> В debian принято отладочные символы в отдельные deb упаковывать, их просто нужно > поставить и у вас появятся отладочные символы в отладчике. Это в редхате. Да, они раньше паковали debuginfo.. К 9 например.. но почему-то к последним версиям перестали. Видимо, багрепортов больше не ждут.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Мелкий (?), 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ообщить модератору


	48. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 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ообщить модератору


	51. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 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ообщить модератору


	52. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Мелкий (?), 18-Ноя-20, 00:11
	Ну, к rpm репе действительно есть вопросы... А даже вот такой backtrace на самом деле уже интересен. gtrgm_alloc сам по себе только в pg13 и появился. Вполне бы уже могли натолкнуть в нужную сторону. 13.2 будет 11 февраля, через полгода 13.3 уже.
	Ответить \| Правка \| К родителю #48 \| Наверх \| Cообщить модератору


	45. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от тральшик (?), 16-Ноя-20, 07:33
	http://apt.postgresql.org/pub/repos/apt/pool/main/p/postgres... не оно?
	Ответить \| Правка \| К родителю #34 \| Наверх \| Cообщить модератору


	49. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Анонимленьлогиниться (?), 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ообщить модератору


	33. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от JL2001 (ok), 15-Ноя-20, 00:16
	>> А багу зарегали? > Нет. Как ни пытался, не смог сделать минимальное воспроизведение сообщите хотяб в таком виде, возможно, вам там напишут или волшебные флаги или способ диагностики или помогут с минимизацией или созданием абстрактного набора данных для теста
	Ответить \| Правка \| К родителю #26 \| Наверх \| Cообщить модератору


	36. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от 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ообщить модератору


	37. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Anon_noXX (?), 15-Ноя-20, 04:54
	Впрочем, я погорячился, товарищи из Core Team проблему подтверждают. Сорри.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от Anon_noXX (?), 15-Ноя-20, 04:57
	И опять я не прав, переписка-то 2019 годом заканчивается :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Обновление PostgreSQL с устранением уязвимостей"	+/–
	Сообщение от JL2001 (ok), 15-Ноя-20, 15:36
	> И опять я не прав, переписка-то 2019 годом заканчивается :) так ворвитесь в тред и апните топик может у них не на ком воспроизвести зы: а вы пробовали на копии бд заменить боевые данные рандомными значениями и воспроизвести на этом уже не секретном инстансе? зыы: после экспорта+импорт чере sql воспроизводится? тоесть не зависит от раскладки данных по секторам? зыыы: ну и на другую фс точно так же можно попробовать перетащить на какой-нить тестовой машине или вообще через mount loop образа фс, а не на реальной фс
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Обновление PostgreSQL с устранением уязвимостей"	+1 +/–
	Сообщение от Анонимленьлогиниться (?), 15-Ноя-20, 18:01
	>> И опять я не прав, переписка-то 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ообщить модератору