Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM

From: Cherio <cherio(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 18:06:45
Message-ID: CAKHqFkL3Ms6NzZ9_9UbpN3Qr0UKHdHisRH=JkeGYirYRhg0R7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The second script should have tables used in the reversed order:

UPDATE tableA
UPDATE tableB

and

UPDATE tableB
UPDATE tableA

Since they will run in individual transactions tableA gets locked by the
1st script and tableB by the 2nd; as execution flow proceeds to the next
update in each script, those tables would be locked in separate
transactions.

On Mon, Feb 27, 2023 at 1:00 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Cherio <cherio(at)gmail(dot)com> writes:
> > I just realized that the ramifications of this change go further than
> just
> > VACUUM related statements in the scripts. Assume 2 scripts
>
> > UPDATE tableA
> > UPDATE tableB
>
> > and
>
> > UPDATE tableA
> > UPDATE tableB
>
> > Before the change they could run in parallel without issues. After the
> > change this will cause one of the queries to fail due to transaction
> locks.
>
> Uh ... really? Please provide evidence. AFAIK this set of changes
> only affects commands that are meant to not run inside tranaction blocks.
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-02-27 18:11:02 Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM
Previous Message Tom Lane 2023-02-27 18:00:01 Re: BUG #17810: Update from 13.09 to 13.10 breaks SQLs with VACUUM