From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
Cc: | Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add Pipelining support in psql |
Date: | 2024-11-27 12:54:45 |
Message-ID: | CAGECzQQ6pdK3jjP_9nYa7M=DABcehfKMCXy=bGi1Sh7U_dyYRw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 27 Nov 2024 at 13:05, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
> ```
> db1=# \startpipeline
> db1=# begin \parse p1
> db1=*#
> ```
> Notice the asterisks that appeared after parse the message. This
> typically indicates we are in the tx block. this is however untrue
> before the bind+exec message for p1 will be sent (\bind_name
> metacommand). Am I correct?
This behaviour is expected, it also happens if you send "SELECT 1"
instead of "begin" in the parse message:
db1=# \startpipeline
db1=# SELECT 1 \parse p1
db1=*#
The reason this happens is that the first command in a pipeline sent
to the server opens an implicit transaction. See the "implicit COMMIT"
wording here[1], or look at this code in exec_parse_message:
/*
* Start up a transaction command so we can run parse analysis etc. (Note
* that this will normally change current memory context.) Nothing happens
* if we are already in one. This also arms the statement timeout if
* necessary.
*/
start_xact_command();
[1]: https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-PIPELINING
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-11-27 12:57:57 | Re: Index AM API cleanup |
Previous Message | Heikki Linnakangas | 2024-11-27 12:54:27 | Re: Typo in comment of auto_explain.c |