Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
От | Tom Lane |
---|---|
Тема | Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti |
Дата | |
Msg-id | 799185.1752535067@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti |
Список | pgsql-bugs |
I wrote: > BTW, d55322b0d simply made it easy to trigger the bug from psql. > If I use current psql to connect to older servers, I can demonstrate > crashes (or sometimes "stack depth limit exceeded") back to v12. I think I fat-fingered something, because now I can only reproduce back to v13. Bisecting says the crash started at the v13-era commit commit 2f9661311b83dc481fc19f6e3bda015392010a40 Author: Alvaro Herrera <alvherre@alvh.no-ip.org> Date: Mon Mar 2 18:19:51 2020 -0300 Represent command completion tags as structs which is unsurprising because that's what introduced the Assert we're hitting. BTW, with Asserts disabled it works fine: $ psql postgres psql (19devel) Type "help" for help. postgres=# \parse s postgres=# execute s; EXECUTE which is another reason not to start throwing an error. (I did not look into how come that works... the correct command tag must be getting filled in later, but where?) regards, tom lane
В списке pgsql-bugs по дате отправления: