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 20:09:00
Message-ID: CAKFQuwZmBiugpSwBGkHN_pTYgpFTkxfnMf-xCA8xuVpdj+TT8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

> Hello David,
> Thanks for your answer.
> The actual problem is that my SELECT query is being executed meanwhile the
> UPDATE one, but instead of waiting for the UPDATE to be executed, it
> doesn't wait and gets the value from the field prior to the update.
> I believed it was because of the MVCC, and I was looking for a workaround
> to force the select to wait for the UPDATE to finish, instead of taking
> values of a snapshot.
>
>>
>>
If you can demonstrate a case where session 1 is holding a transaction open
on a completed UPDATE statement and session 2 with a SELECT FOR UPDATE is
not waiting for session 1 to commit I am pretty sure you will be
demonstrated a bug.

"conversely, SELECT FOR UPDATE will wait for a concurrent transaction that
has run any of those commands on the same row, and will then lock and
return the updated row (or no row, if the row was deleted)."

https://www.postgresql.org/docs/12/explicit-locking.html#LOCKING-ROWS

David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-04-25 21:49:40 Re: BUG #16390: Regression between 12.2 and 11.6 on a recursive query : very slow and overestimation of rows
Previous Message Eudald Valcàrcel Lacasa 2020-04-25 19:44:06 Re: Queries getting older values (autocommit enabled)