Re: a SELECT FOR UPDATE question - Mailing list pgsql-general

From Tom Lane
Subject Re: a SELECT FOR UPDATE question
Date
Msg-id 26510.1108047229@sss.pgh.pa.us
Whole thread Raw
In response to Re: a SELECT FOR UPDATE question  (Michael Fuhr <mike@fuhr.org>)
Responses Re: a SELECT FOR UPDATE question
List pgsql-general
Michael Fuhr <mike@fuhr.org> writes:
> xactA: updates row
> xactB: attempts to update same row, blocks until xactA completes
> xactC: query finds xactA in row's xmax
> xactA: commits
> xactB: unblocks and acquires a lock on the row
> xactC: query to pg_locks doesn't find xactA, so assumes row not locked

> Does that sound like what you're talking about?

Right.  Furthermore, xactC's query result could have been stale when it
was obtained, nevermind the separate query to pg_locks:

xactA: updates row
xactC: starts, sets snapshot
xactB: attempts to update same row, blocks until xactA completes
xactA: commits
xactB: unblocks and acquires a lock on the row
xactC: query finds xactA in row's xmax because of MVCC rules

            regards, tom lane

pgsql-general by date:

Previous
From: Christopher Browne
Date:
Subject: Re: Functions with more than 32 parameters
Next
From: "Ed L."
Date:
Subject: Re: Understanding EXPLAIN ANALYZE output