BUG #18333: Postgres is crashing if we have special character in the query

Started by PG Bug reporting formabout 2 years ago4 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 18333
Logged by: Sujeet Swaminath
Email address: sujeet.cha@gmail.com
PostgreSQL version: 14.10
Operating system: RHEL9.3
Description:

Hi,

I have installed Postgres-14.10 and when executing the below query, the
postgres crashes. but the same query work well with PostgreSQL-14-9.
I have a crash dump, but not sure, how can I attach it here.

2024-02-05 06:08:53.936 GMT [1680576] LOG: server process (PID 2627861) was
terminated by signal 11: Segmentation fault
2024-02-05 06:08:53.936 GMT [1680576] DETAIL: Failed process was running:
SELECT DISTINCT badsql.id_code,badsql.id_nr FROM badsql LEFT OUTER JOIN
newsql on badsql.id_nr = newsql.id_nr and badsql.vk_ek%2=newsql.ku_vk_ek;
2024-02-05 06:08:53.936 GMT [1680576] LOG: terminating any other active
server processes
2024-02-05 06:08:53.937 GMT [2627876] FATAL: the database system is in
recovery mode
2024-02-05 06:08:53.951 GMT [1680576] LOG: all server processes terminated;
reinitializing
2024-02-05 06:08:54.475 GMT [2627879] LOG: database system was interrupted;
last known up at 2024-02-04 23:05:12 GMT
2024-02-05 06:08:54.506 GMT [2627879] LOG: database system was not properly
shut down; automatic recovery in progress
2024-02-05 06:08:54.506 GMT [2627879] LOG: redo starts at 17/B72551A0
2024-02-05 06:08:54.506 GMT [2627879] LOG: invalid record length at
17/B7255288: wanted 24, got 0
2024-02-05 06:08:54.506 GMT [2627879] LOG: redo done at 17/B7255250 system
usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2024-02-05 06:08:54.577 GMT [1680576] LOG: database system is ready to
accept connections
2024-02-05 06:14:55.063 GMT [1680576] LOG: received fast shutdown request
2024-02-05 06:14:55.064 GMT [1680576] LOG: aborting any active
transactions
2024-02-05 06:14:55.065 GMT [1680576] LOG: background worker "logical
replication launcher" (PID 2627885) exited with exit code 1
2024-02-05 06:14:55.079 GMT [2627880] LOG: shutting down
2024-02-05 06:14:55.208 GMT [1680576] LOG: database system is shut down

#2Michael Paquier
michael@paquier.xyz
In reply to: PG Bug reporting form (#1)
Re: BUG #18333: Postgres is crashing if we have special character in the query

On Mon, Feb 05, 2024 at 10:30:33AM +0000, PG Bug reporting form wrote:

I have installed Postgres-14.10 and when executing the below query, the
postgres crashes. but the same query work well with PostgreSQL-14-9.
I have a crash dump, but not sure, how can I attach it here.

2024-02-05 06:08:53.936 GMT [1680576] LOG: server process (PID 2627861) was
terminated by signal 11: Segmentation fault
2024-02-05 06:08:53.936 GMT [1680576] DETAIL: Failed process was running:
SELECT DISTINCT badsql.id_code,badsql.id_nr FROM badsql LEFT OUTER JOIN
newsql on badsql.id_nr = newsql.id_nr and badsql.vk_ek%2=newsql.ku_vk_ek;

It is going to be hard to say what's wrong without more details, like
a backtrace, or even better a self-contained SQL sequence that makes a
problem reproducible. 14.11 is planned for this week, so you may want
to give it a try and double-check if your problem is going away:
https://www.postgresql.org/developer/roadmap/
--
Michael

#3Sujeet Swaminath
sujeet.cha@gmail.com
In reply to: Michael Paquier (#2)
Re: BUG #18333: Postgres is crashing if we have special character in the query

Hi Michael,

Using the latest PostgreSQL 14 release version (14.11), I was able to
reproduce this issue by executing the provided query, resulting in a crash.
Attached are the crash dump and a sample database in tar format.

below is the login and the schema details that I have used,

create role badsql login password 'test123' createdb valid until
'infinity';
create database "TEST" with encoding='UTF8' connection limit=-1;
\c TEST
create schema badsql authorization badsql;
grant all on schema badsql to badsql;
alter user badsql set search_path = badsql;
alter user badsql with superuser;

and to crash the postgres, you can use the below query.

SELECT DISTINCT htest.test_code,htest.new_nr FROM htest LEFT OUTER JOIN

ktest on htest.new_nr = ktest.test_nr and htest.test_ek%2=ktest.test_ek;

Note: soon after importing the DB it will not crash, you have to exit the
psql session and start a new session, then within 5-10 execution of this
query it should crash.

Thanks,
Sujeet

On Tue, Feb 6, 2024 at 5:32 AM Michael Paquier <michael@paquier.xyz> wrote:

Show quoted text

On Mon, Feb 05, 2024 at 10:30:33AM +0000, PG Bug reporting form wrote:

I have installed Postgres-14.10 and when executing the below query, the
postgres crashes. but the same query work well with PostgreSQL-14-9.
I have a crash dump, but not sure, how can I attach it here.

2024-02-05 06:08:53.936 GMT [1680576] LOG: server process (PID 2627861)

was

terminated by signal 11: Segmentation fault
2024-02-05 06:08:53.936 GMT [1680576] DETAIL: Failed process was

running:

SELECT DISTINCT badsql.id_code,badsql.id_nr FROM badsql LEFT OUTER JOIN
newsql on badsql.id_nr = newsql.id_nr and

badsql.vk_ek%2=newsql.ku_vk_ek;

It is going to be hard to say what's wrong without more details, like
a backtrace, or even better a self-contained SQL sequence that makes a
problem reproducible. 14.11 is planned for this week, so you may want
to give it a try and double-check if your problem is going away:
https://www.postgresql.org/developer/roadmap/
--
Michael

Attachments:

crash_details.zipapplication/x-zip-compressed; name=crash_details.zipDownload+14-18
#4Michael Paquier
michael@paquier.xyz
In reply to: Sujeet Swaminath (#3)
Re: BUG #18333: Postgres is crashing if we have special character in the query

On Tue, May 07, 2024 at 04:49:55PM +0400, Sujeet Swaminath wrote:

Note: soon after importing the DB it will not crash, you have to exit the
psql session and start a new session, then within 5-10 execution of this
query it should crash.

Note for the archives: Sujeet has mentioned to me offlist that 14.12
has fixed his problem, so there is nothing to look at here, I guess.
--
Michael