Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
