Devrim GUNDUZ wrote:
[ PGP not available, raw data follows ]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi,
>
> AFAIR there was a thread about "SELECT FOR UPDATE NOWAIT" availability in
> {7.5,8.0}, 7-8 months ago.
>
> Now we have LOCK TABLE ... NOWAIT; but I wonder whether we'll have the
> SELECT ... NOWAIT one. Today I got a request for this; and it was
> reported that this feature will be used in a huge project.
>
> If there is an unapplied patch that I've missed (even though I didn't see
> one in http://momjian.postgresql.org/cgi-bin/pgpatches2), I'd like to
> know it -- taking all the risks, surely.
I don't know of any patch done. The solution suggested was to use
statement_timeout before the SELECT FOR UPDATE. I am not 100% excited
about that because there is no way to know if the query is slow because
of a lock or just system slowness, but the logic is that you really
don't care why you have failed to do a lock or not, just that the query
is taking a long time. It does solve the problem and allow us to not
add NOWAIT to UPDATE and DELETE too. The other problem is that queries
do a lot of locking (think system tables) so there is no way to know
which locks we shouldn't wait for. At last LOCK specifies the object,
but of course it doesn't do row-level control.
Care to suggest an FAQ.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
