Re: NO WAIT ... - Mailing list pgsql-patches

From Tom Lane
Subject Re: NO WAIT ...
Date
Msg-id 24827.1077129458@sss.pgh.pa.us
Whole thread Raw
In response to Re: NO WAIT ...  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: NO WAIT ...
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I imagine folks would want it on UPDATE, DELETE, and VACUUM FULL too,

Why?  You can do a SELECT FOR UPDATE first and then you know that you
have the row lock.  There's no need for any special handling of UPDATE
or DELETE.  I don't see the applicability to VACUUM, either.

BTW, one idea I was thinking about was that a SELECT FOR UPDATE NOWAIT
behavior might simply not return the rows it couldn't acquire lock on,
instead of erroring out.  Not sure if this would be more or less useful
than the error behavior, but I can definitely think of possible
applications for it.

> Also, I don't see this changing sematics like the regex flavor did.

You're kidding.  This is a much more fundamental change of behavior than
whether some seldom-used regex features work.  In particular, we know
that the regex behavior does not affect any other part of the system.
I do not think any equivalent safety claims can be made for random
hacking of whether LockAcquire succeeds or not.

            regards, tom lane

pgsql-patches by date:

Previous
From: Hans-Jürgen Schönig
Date:
Subject: Re: NO WAIT ...
Next
From: Bruce Momjian
Date:
Subject: Re: NO WAIT ...