From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Zechman, Derek S" <Derek.S.Zechman@snapon.com>
cc: "pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>
Subject: Re: segmentation fault
In-reply-to: <PH0PR04MB82948BA63F4311389716E1F0C0BA2@PH0PR04MB8294.namprd04.prod.outlook.com>
References: <PH0PR04MB82948BA63F4311389716E1F0C0BA2@PH0PR04MB8294.namprd04.prod.outlook.com>
Comments: In-reply-to "Zechman, Derek S" <Derek.S.Zechman@snapon.com>
	message dated "Wed, 23 Apr 2025 11:52:42 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1436821.1745436200.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Apr 2025 15:23:20 -0400
Message-ID: <1436822.1745436200@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1436822.1745436200%40sss.pgh.pa.us>
Precedence: bulk

"Zechman, Derek S" <Derek.S.Zechman@snapon.com> writes:
> We are getting a segmentation fault which seems to be specific to pg16 o=
n redhat 8.  Tested on pg14 and pg15 with no problems.  Also tested with p=
g16 on redhat 9 - no issues.  The developer determined that it is specific=
 to select into a defined variable within a function.  We have a reproduci=
ble test case that requires no data.  I determined that 2857 is the maximu=
m number that doesn't crash and anything higher than that causes a segfaul=
t.  Can anyone help with this problem?

FWIW, I cannot replicate this problem using this script.  Now I'm
testing v16 branch tip not 16.6, but a quick trawl through the git
history didn't find any plausibly-matching bug fixes since 16.6.

Where did you get your Postgres server executable from exactly,
and what options was it built with?  (The output of the matching
version of pg_config would answer that.)  Can you get a stack
trace from the crash?

https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_=
backend

			regards, tom lane