From: Tom Lane <tgl@sss.pgh.pa.us>
To: kdavydenka@gmail.ru
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17655: crash postgres by query
In-reply-to: <17655-c56446e34b34eb86@postgresql.org>
References: <17655-c56446e34b34eb86@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 20 Oct 2022 14:16:55 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3041791.1666277875.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 20 Oct 2022 10:57:55 -0400
Message-ID: <3041792.1666277875@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3041792.1666277875%40sss.pgh.pa.us>
Precedence: bulk

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 fau=
lt  =

>  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