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.
regards, tom lane
