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

Re: NO WAIT ...

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(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:43:47
Message-ID: 200402181843.i1IIhlO21943@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> 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.

Why bother when you can do it without the SELECT FOR UPDATE?

> 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

No, I am not.

> 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.

It throws an error. I don't see how that could cause actual data
corruption or invalid data.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-02-18 18:45:18
Subject: Re: NO WAIT ...
Previous:From: Tom LaneDate: 2004-02-18 18:37:38
Subject: Re: NO WAIT ...

pgsql-patches by date

Next:From: Tom LaneDate: 2004-02-18 18:45:18
Subject: Re: NO WAIT ...
Previous:From: Tom LaneDate: 2004-02-18 18:37:38
Subject: Re: NO WAIT ...

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