Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM
Date
Msg-id CAKFQuwajJehk7WA++QmjKfUscZeUDU8ujSZBk012t8e3bBDMig@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Feb 27, 2023 at 1:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> As for your usage of "conn.setAutocommit(true)" - IIUC that is irrelevant
> to this entire discussion.  You've chosen to bundle up multiple statements
> into a single Statement.execute(string) call which obeys the rules of the
> simple query protocol - multiple statements:

I doubt it.  We closed the not-in-transaction-block loophole decades
ago for simple query protocol.  What's at stake here is what happens
when a series of extended-protocol commands are given without Sync
between them, which we interpret as a request to run them all in the
same transaction.  I'm a bit surprised that the JDBC driver is choosing
to issue them that way, because it implies (at least) that it's parsing
the string enough to break it down into separate SQL commands.  But
we'd not be having this conversation if that weren't happening.

Yeah, I realized a bit after I wrote my comments that it is similar but not exactly this issue.  And yes, the JDBC driver does indeed go to the trouble of parsing out statements.

David J.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM
Next
From: Tom Lane
Date:
Subject: Re: BUG #17811: Replacing an underlying view breaks OLD/NEW tuple when accessing it via upper-level view