Re: [bug fix] Savepoint-related statements terminates connection
Catalin Iacob <iacobcatalin@gmail.com>
From: Catalin Iacob <iacobcatalin@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>,
Simon Riggs <simon@2ndquadrant.com>, "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-09-08T17:24:44Z
Lists: pgsql-hackers
On Thu, Sep 7, 2017 at 8:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I've pushed up an attempt at this:
>
>
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=b976499480bdbab6d69a11e47991febe53865adc
>
> Feel free to suggest improvements.
Thank you, this helps a lot. Especially since some of the behavior is a bit
surprising, for example stopping on error leading to ROLLBACK not being
done and the retroactive upgrade of preceding commands in an implicit block
to a transaction block when a BEGIN appears.
When reading this I also realized that the backend does send responses for
every individual query in a multi-query request, it's only libpq's PQexec
that throws away the intermediate results and only provides access to the
last one. I always thought the backend did that. The docs hinted that it's
the frontend ("psql only prints the last one", "PGresult describes the
result of the last command") but to assure myself I looked with tcpdump.
It's a pity that the underlying protocol has 2 ways to do batching of
queries but the official library hides both. I guess I should go review the
"Batch/pipelining support for libpq" patch rather than complaining.
Commits
-
Improve documentation about behavior of multi-statement Query messages.
- b976499480bd 11.0 landed
-
Fix handling of savepoint commands within multi-statement Query strings.
- 6eb52da3948d 11.0 landed
-
Arrange for PreventTransactionChain to reject commands submitted as part
- 4f896dac17f7 8.3.0 cited