Thread: BUG #17655: crash postgres by query
The following bug has been logged on the website: Bug reference: 17655 Logged by: Kos Dav Email address: kdavydenka@gmail.ru PostgreSQL version: 10.19 Operating system: Red Hat Enterprise Linux Server 7.8 (Maipo) Description: log from journalctl Oct 20 14:52:21 server1 kernel: show_signal_msg: 537 callbacks suppressed Oct 20 14:52:21 server1 kernel: postgres[9328]: segfault at 1e88ff3 ip 00007f55ad8414ff sp 00007fff0031e7f8 error 4 in libc-2.17.so[7f55ad6eb000+1c3000] Oct 20 14:52:21 server1 abrt-hook-ccpp[9329]: Process 35274(postgres) of user 26 killed by SIGSEGV - dumping core log from postgres server process (PID 35274) was terminated by signal 11: Segmentation fault Failed process was running: select customer_id, birth_place from last_golden_record lgr where birth_place like U&'%\000A%'
Hi, On Thu, Oct 20, 2022 at 02:16:55PM +0000, PG Bug reporting form wrote: > The following bug has been logged on the website: > > Bug reference: 17655 > Logged by: Kos Dav > Email address: kdavydenka@gmail.ru > PostgreSQL version: 10.19 > Operating system: Red Hat Enterprise Linux Server 7.8 (Maipo) > Description: > > log from journalctl > Oct 20 14:52:21 server1 kernel: show_signal_msg: 537 callbacks suppressed > Oct 20 14:52:21 server1 kernel: postgres[9328]: segfault at 1e88ff3 ip > 00007f55ad8414ff sp 00007fff0031e7f8 error 4 in > libc-2.17.so[7f55ad6eb000+1c3000] > Oct 20 14:52:21 server1 abrt-hook-ccpp[9329]: Process 35274(postgres) of > user 26 killed by SIGSEGV - dumping core > > > log from postgres > server process (PID 35274) was terminated by signal 11: Segmentation fault > Failed process was running: > select customer_id, birth_place from last_golden_record lgr where > birth_place like U&'%\000A%' Unfortunately this isn't enough information to understand the problem. However a common cause for a SIGSEGV on a query like that is some corruption on the table. Could you try to get a stack trace? See https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_randomly_crashing_backend.
PG Bug reporting form <noreply@postgresql.org> writes: > Oct 20 14:52:21 server1 kernel: postgres[9328]: segfault at 1e88ff3 ip > 00007f55ad8414ff sp 00007fff0031e7f8 error 4 in > libc-2.17.so[7f55ad6eb000+1c3000] > Oct 20 14:52:21 server1 abrt-hook-ccpp[9329]: Process 35274(postgres) of > user 26 killed by SIGSEGV - dumping core > log from postgres > server process (PID 35274) was terminated by signal 11: Segmentation fault > Failed process was running: > select customer_id, birth_place from last_golden_record lgr where > birth_place like U&'%\000A%' With neither a stack trace nor a reproducible test case, there is little anyone can do with this report. There's some info about extracting stack traces from crashes at https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend but if you could make a self-contained test case that'd be even better. Also: it's possible that this is less about a software bug than about corrupt data. Of course, we'd prefer the server not crash on corrupt data, but sometimes that happens. A simple thing to do that might help in such a case is to REINDEX whatever index(es) the query is using. But first see https://wiki.postgresql.org/wiki/Corruption Also: the 10.x series will reach EOL next month. You should be seriously working on updating to some later release branch. Whether doing so will provide a fix for this problem is hard to say, but it's not out of the question. regards, tom lane