Date: Wed, 14 Jan 2026 06:50:59 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Subject: Re: Cleaning up PREPARE query strings?
Message-ID: <aWbMU6wKpYkJHPP5@jrouhaud>
References: <aUwKEWGge5jWtaRX@jrouhaud>
 <928501.1766593260@sss.pgh.pa.us>
 <aWNWO8wEvu6YQaKN@jrouhaud>
 <CAA5RZ0sswD2h2w8FkVjToA=3oNYUb1mW-zuCD=J6DDK2zuLuZg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAA5RZ0sswD2h2w8FkVjToA=3oNYUb1mW-zuCD=J6DDK2zuLuZg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aWbMU6wKpYkJHPP5%40jrouhaud>
Precedence: bulk

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.