Re: NO WAIT ...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-patches(at)postgresql(dot)org
Subject: Re: NO WAIT ...
Date: 2004-02-18 18:37:38
Message-ID: 24827.1077129458@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-02-18 18:43:47 Re: NO WAIT ...
Previous Message Hans-Jürgen Schönig 2004-02-18 18:27:10 Re: NO WAIT ...

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-02-18 18:43:47 Re: NO WAIT ...
Previous Message Hans-Jürgen Schönig 2004-02-18 18:27:10 Re: NO WAIT ...