Re: Cleaning up PREPARE query strings? - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Cleaning up PREPARE query strings?
Date
Msg-id aWbMU6wKpYkJHPP5@jrouhaud
Whole thread Raw
In response to Re: Cleaning up PREPARE query strings?  (Sami Imseih <samimseih@gmail.com>)
List pgsql-hackers
Hi,

On Tue, Jan 13, 2026 at 02:24:51PM -0600, Sami Imseih wrote:
> I was looking a bit more here, and I found that this patch breaks if
> pg_stat_statements is enabled.
>
> ```
> postgres=# SELECT 'bingo'\;  PREPARE q1 AS SELECT 1 AS a \; SELECT 42;
> server closed the connection unexpectedly
>     This probably means the server terminated abnormally
>     before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> The connection to the server was lost. Attempting reset: Failed.
> !?>
> ```
>
> This is because the raw statement location is set to 0 with the patch which
> breaks generate_nromalized_query when trying to deal with a multi command
> statement. So, I don't think the way v1 is doing things will actually work.

That's very strange.  I'm pretty sure that I tried since the earlier approach I
mentioned using doing it in CreateCachedPlan() had that exact problem.

Also, src/test/recovery/t/027_stream_regress.pl does run the full regression
tests with pg_stat_statements enabled, and it doesn't fail.

I'm not sure what is different in your case.



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Eagerly evict bulkwrite strategy ring
Next
From: Jacob Champion
Date:
Subject: Re: [oauth] SASL mechanisms