А extension какие-то установлены? shared_preload_library в конфиге postgres?

#shared_preload_libraries = '' # (change requires restart)

я бы поставил пакет с отладочными символами postgres и libc, подключился бы gdb к зависшей сессии с insert и выполнил бы в gdb команду bt, это покажет в каком месте исходного кода postgres он в этот момент находится и уже от этого продолжал бы разбирательство

попробую провернуть такой фокус, спасибо

Картина вот такая: (gdb) bt #0 0x00007f8156b95f0d in sem_post@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #1 0x00000000006e03a2 in PGSemaphoreUnlock () #2 0x00000000007556bc in LWLockRelease () #3 0x00000000004da391 in _bt_relandgetbuf () #4 0x00000000004df237 in _bt_moveright () #5 0x00000000004df471 in _bt_search () #6 0x00000000004d96cd in _bt_doinsert () #7 0x00000000004dc961 in btinsert () #8 0x000000000061558a in ExecInsertIndexTuples () #9 0x000000000063a729 in ExecInsert () #10 0x000000000063ba41 in ExecModifyTable () #11 0x0000000000616192 in standard_ExecutorRun () #12 0x0000000000765fea in ProcessQuery () #13 0x00000000007662be in PortalRunMulti () #14 0x0000000000766d85 in PortalRun () #15 0x0000000000762f34 in exec_simple_query () #16 0x00000000007641a2 in PostgresMain () #17 0x00000000004844de in ServerLoop () #18 0x00000000006f32a3 in PostmasterMain () #19 0x00000000004853e3 in main ()

интересно, bt — это функции btree индекса

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

это похоже на баг в postgres или баг/повреждение семафоров в glibc (хотя тогда бы по идеи тоже просто ошибку писало)

а это докер или голое железо?

Странно, gdb вроде номера строк ещё писал. Попробуйте gdb -full запостить на pastebin какой-нибудь. А, и да, какая версия postgres?

это был докер из под патрони, были проблемы другого рода, переехали на железо, просто запустив постгре с железа и подсунув ему дату. Версия постгрес 12,7

Как за две секунды сломать мозг, читателям, хе-хе. Ну, данные всё-таки, а не дату. В английском-то data и date нормально разичаются!

Ой, простите, bt -full . Что-то я не проснулся, да.

Кстати, ещё интересны версии ядра и glibc. И поставить libc6-dbg, если есть в дистрибутиве. Вообще, на первый взгляд выглядит как баг в libc.

И версию libc заодно скажыте, да.

sem_post@@GLIBC_2.2.5 () - это оно? ядро 3,10,0,-1160

glibc-2.17

Ага, интересно.

сервак с базой без инета, пока не могу туда поставить debuginfo, rpm ставлю, все равно не видит

Но вряд ли таким будут заниматься -- это очень старый glibc, и sem_post с тех пор, кажэтся, полтора раза переписали...

вы к тому, что если это баг?

Ну, очень похожэ на баг glibc, да.

8.5 лет релизу. По компьютэрным меркам это ужэ археология.

А в качестве временной заплатки -- http://web.mit.edu/gnu/doc/html/gdb_toc.html#SEC96

return вызвать из gdb? попробую. Спасибо

Только лучшэ, наверное, всё-таки glibc return. Безопаснее -- там почти ничего ужэ меняться не должно. И с правильным кодом (0 кажэтся для sem_post ?)

Спасибо, попробую