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:58:11
Message-ID: 200402181858.i1IIwBf24047@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:
> > Tom Lane wrote:
> >> 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?
> 
> Because you want the extra feature?
> 
> > It throws an error. I don't see how that could cause actual data
> > corruption or invalid data.
> 
> I am concerned about what behavior will stop working nicely when locks
> that normally always succeed suddenly error out instead.  Perhaps it
> won't corrupt your database, but that doesn't mean that the behavior
> will be pleasant.
> 
> As an example: the proposed patch is able to cause an error instead of
> waiting for access-share locks.  Suppose you actually turn that on, and
> then try to call some function, and the resulting attempt to read
> pg_proc errors out because someone was transiently holding a conflicting
> lock.  This means your application fails, randomly, and in
> hard-to-reproduce ways.  Not only would the failure or not-failure
> depend on what other people were doing, it'd depend on whether you'd
> already cached the function definition (if so, no lock would actually
> get taken on pg_proc during the call).
> 
> I think a feature narrowly focused on suppressing waits for specific
> locks (like the lock on a specific row that you're trying to update)
> would be useful.  Implementing something that affects *every* lock in
> the system is nothing more nor less than a foot-gun, because you could
> never be very certain what lock attempts would fail.

The original idea I had was for the GUC variable to affect only
exclusive locks.  If we want more, we can add it later.  I agree the
extra GUC which controls the types of locks we will nowait for seems
pretty useless.

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

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-02-18 19:12:46
Subject: Re: [PATCHES] NO WAIT ...
Previous:From: Bruce MomjianDate: 2004-02-18 18:56:14
Subject: Re: [PATCHES] NO WAIT ...

pgsql-patches by date

Next:From: Tom LaneDate: 2004-02-18 19:12:46
Subject: Re: [PATCHES] NO WAIT ...
Previous:From: Bruce MomjianDate: 2004-02-18 18:56:14
Subject: Re: [PATCHES] NO WAIT ...

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