Re: Cleaning up PREPARE query strings?

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cleaning up PREPARE query strings?
Date: 2026-01-13 22:50:59
Message-ID: aWbMU6wKpYkJHPP5@jrouhaud
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2026-01-13 23:13:11 Re: [oauth] SASL mechanisms
Previous Message Melanie Plageman 2026-01-13 22:30:58 Re: Eagerly evict bulkwrite strategy ring