Re: Queries getting older values (autocommit enabled)

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Eudald Valcàrcel Lacasa <eudald(dot)valcarcel(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Queries getting older values (autocommit enabled)
Date: 2020-04-25 19:36:20
Message-ID: CAKFQuwZ2_-Rd4v6wrDWBX9SZWfibOzHHJbRn4OhpKn3KBcCOCg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Apr 25, 2020 at 12:07 PM Eudald Valcàrcel Lacasa <
eudald(dot)valcarcel(at)gmail(dot)com> wrote:

> Hello again,
> I've been looking for this issue and I'd like to know the behavior of FOR
> UPDATE SKIP LOCKED in the following scenario:
> * One query does an UPDATE targeting a row in the table
> * Another query run in parallel does a SELECT...FOR UPDATE SKIP LOCKED
> targeting the same (being updated) row on the table.
> From SKIP LOCKED definition: . With SKIP LOCKED, any selected rows that
> cannot be immediately locked are skipped.
>
> Would it mean that the 2nd query wouldn't check the affected row since
> it's locked by the first query?
>

Yes. What else would it mean?

If that's the behavior, is there any way I could make the SELECT query wait
> for the UPDATE LOCK? Is it recommended? Are there downsides to this
> approach?
>
>>
>>>
"To prevent the operation from waiting for other transactions to commit,
use either the NOWAIT or SKIP LOCKED option."

Which means that if you don't include the NOWAIT clause you, well, wait.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Eudald Valcàrcel Lacasa 2020-04-25 19:44:06 Re: Queries getting older values (autocommit enabled)
Previous Message Eudald Valcàrcel Lacasa 2020-04-25 19:06:56 Re: Queries getting older values (autocommit enabled)