From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Cherio <cherio(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM |
Date: | 2023-02-27 20:36:44 |
Message-ID: | CAKFQuwajJehk7WA++QmjKfUscZeUDU8ujSZBk012t8e3bBDMig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Feb 27, 2023 at 1:21 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-27 21:35:49 | Re: BUG #17811: Replacing an underlying view breaks OLD/NEW tuple when accessing it via upper-level view |
Previous Message | Tom Lane | 2023-02-27 20:21:16 | Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM |