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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to