Re: Cleaning up PREPARE query strings?
| От | Julien Rouhaud |
|---|---|
| Тема | Re: Cleaning up PREPARE query strings? |
| Дата | |
| Msg-id | aWbMU6wKpYkJHPP5@jrouhaud обсуждение исходный текст |
| Ответ на | Re: Cleaning up PREPARE query strings? (Sami Imseih <samimseih@gmail.com>) |
| Ответы |
Re: Cleaning up PREPARE query strings?
|
| Список | 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 по дате отправления: