Skip site navigation (1) Skip section navigation (2)

Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Date: 2009-05-11 14:46:41
Message-ID: 291.1242053201@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Hans-Juergen Schoenig <postgres(at)cybertec(dot)at> writes:
> i would like to propose an extension to our SELECT FOR UPDATE mechanism.
> especially in web applications it can be extremely useful to have the 
> chance to terminate a lock after a given timeframe.

I guess my immediate reactions to this are:

1. Why SELECT FOR UPDATE in particular, and not other sorts of locks?

2. That "clear and easy to use" oracle syntax sucks.  You do not want
to be embedding lock timeout constants in your application queries.
When you move to a new server and the appropriate timeout changes,
do you want to be trying to update your clients for that?

What I think has been proposed previously is a GUC variable named
something like "lock_timeout", which would cause a wait for *any*
heavyweight lock to abort after such-and-such an interval.  This
would address your point about not wanting to use an overall
statement_timeout, and it would be more general than a feature
that only works for SELECT FOR UPDATE row locks, and it would allow
decoupling the exact length of the timeout from application query
logic.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-05-11 14:52:42
Subject: Re: SSL cert chains patch
Previous:From: Alvaro HerreraDate: 2009-05-11 14:43:17
Subject: Re: [PATCH] Automatic client certificate selectionsupport for libpq v1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group