Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection - Mailing list pgsql-hackers

From Catalin Iacob
Subject Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection
Date
Msg-id CAHg_5goMhkkd6kAoprPpM+2QkLcHRh0CEF4TTpHDNQoPuaOMEw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection
List 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.

pgsql-hackers by date:

Previous
From: Mark Cave-Ayland
Date:
Subject: Re: [HACKERS] More flexible LDAP auth search filters?
Next
From: Jeff Janes
Date:
Subject: Re: [HACKERS] Create replication slot in pg_basebackup if requestedand not yet present