Re: Non-Blocking Locks (i.e. Oracle NOWAIT) - Mailing list pgsql-sql

From Christoph Haller
Subject Re: Non-Blocking Locks (i.e. Oracle NOWAIT)
Date
Msg-id 3F1415B7.9001551F@rodos.fzk.de
Whole thread Raw
In response to Non-Blocking Locks (i.e. Oracle NOWAIT)  (Jan Bernhardt <jb@baltic-online.de>)
Responses Re: Non-Blocking Locks (i.e. Oracle NOWAIT)  (Ang Chin Han <angch@bytecraft.com.my>)
List pgsql-sql
>
> though this question has been asked several times before (but never
really
> answered), I have to give it another try.
>
> I have a multi-user application which synchronizes access to certain
datasets
> via the database itself. If a user has a project in that application
open no
> other user should be able to work on it too. When developing the
application I
> considered the database to be a place to handle the synchronization
since
> transactions are (normally) an integral part of a database system.
When a user
> opens a project the application firstly locks a corresponding row. But
since I
> don't want the application to block if that row is already locked I
use the
> Oracle "NOWAIT" feature (SELECT ... FOR UPDATE NOWAIT) which tries to
receive
> the lock on the specified row and if that row is already locked it
returns
> with an error without blocking and I can tell the user that the
project is
> already in use.
>
> Now that the application is to be ported to PG I need a similar
functionality.
> Is there that an animal? If not, what would you recommend?
>
PostgreSQL 7.3.2
T1: begin; select * from foo for update;
T2: set STATEMENT_TIMEOUT = 1000; -- milliseconds
T2: select * from foo for update;
T2: ERROR:  Query was cancelled.

HTH, Christoph




pgsql-sql by date:

Previous
From: greg@turnstep.com
Date:
Subject: Re: Count dates distinct within an interval
Next
From: Greg Stark
Date:
Subject: Re: summing tables