pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17655: crash postgres by query
3+ messages / 3 participants
[nested] [flat]
* BUG #17655: crash postgres by query
@ 2022-10-20 14:16 PG Bug reporting form <noreply@postgresql.org>
2022-10-20 14:50 ` Re: BUG #17655: crash postgres by query Julien Rouhaud <rjuju123@gmail.com>
2022-10-20 14:57 ` Re: BUG #17655: crash postgres by query Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 3+ messages in thread
From: PG Bug reporting form @ 2022-10-20 14:16 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: kdavydenka@gmail.ru
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%'
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17655: crash postgres by query
2022-10-20 14:16 BUG #17655: crash postgres by query PG Bug reporting form <noreply@postgresql.org>
@ 2022-10-20 14:50 ` Julien Rouhaud <rjuju123@gmail.com>
1 sibling, 0 replies; 3+ messages in thread
From: Julien Rouhaud @ 2022-10-20 14:50 UTC (permalink / raw)
To: kdavydenka@gmail.ru; pgsql-bugs@lists.postgresql.org
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#....
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17655: crash postgres by query
2022-10-20 14:16 BUG #17655: crash postgres by query PG Bug reporting form <noreply@postgresql.org>
@ 2022-10-20 14:57 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 3+ messages in thread
From: Tom Lane @ 2022-10-20 14:57 UTC (permalink / raw)
To: kdavydenka@gmail.ru; +Cc: pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2022-10-20 14:57 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-10-20 14:16 BUG #17655: crash postgres by query PG Bug reporting form <noreply@postgresql.org>
2022-10-20 14:50 ` Julien Rouhaud <rjuju123@gmail.com>
2022-10-20 14:57 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox