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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-02-18 19:12:46 Re: [PATCHES] NO WAIT ...
Previous Message Bruce Momjian 2004-02-18 18:56:14 Re: [PATCHES] NO WAIT ...

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-02-18 19:12:46 Re: [PATCHES] NO WAIT ...
Previous Message Bruce Momjian 2004-02-18 18:56:14 Re: [PATCHES] NO WAIT ...