Re: Detect Locked Row Without Blocking - Mailing list pgsql-general

From Tom Lane
Subject Re: Detect Locked Row Without Blocking
Date
Msg-id 5601.1131462854@sss.pgh.pa.us
Whole thread Raw
In response to Detect Locked Row Without Blocking  (Joe Lester <joe_lester@sweetwater.com>)
Responses Re: Detect Locked Row Without Blocking  (Joe Lester <joe_lester@sweetwater.com>)
List pgsql-general
Joe Lester <joe_lester@sweetwater.com> writes:
> Is there a recommended "postgres way" to determine if a certain row is
> locked... without blocking?

8.1 has a SELECT FOR UPDATE NOWAIT option.  Alternatively, just do a
wait while having a very short statement_timeout.

> In my custom postgres client app I'd like to be able to determine if
> another user is "modifying" a given record. If so, I would present a
> dialog to the user such as "Record Locked. Sam Smith is already
> modifying this record. Try again later."

However, I think the question is moot because it's predicated on a
terrible underlying approach.  You should NEVER design a DB app to hold
a lock while some user is editing a record (and answering the phone,
going out to lunch, etc).  Fetch the data and then let the user edit
it while you are not in a transaction.  When he clicks UPDATE, do
    BEGIN;
    SELECT the row FOR UPDATE;
    check for any changes since you fetched the data originally
    if none, UPDATE and commit
    else rollback and tell user about it

If you do see conflicting changes, then you have enough info to resolve
the conflicts or abandon the update.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Beyond the 1600 columns limit on windows
Next
From: Tino Wildenhain
Date:
Subject: Re: Beyond the 1600 columns limit on windows