On 8/25/10 1:35 PM, Simon Riggs wrote:
> If the row is "key share" locked (as opposed to "tuple share" locks we
> already have), then an UPDATE would only work if it was a non-HOT
> UPDATE. Yes, that would save us some effort in working out whether to
> allow the UPDATE or not. It *is* more restrictive than strictly
> necessary, but much better than the current situation. So at least we
> know that part of it has an easy solution.

I agree that this would be an improvement.

It still has the issue of being baffling to users (why did I get a
deadlock this time, and not THAT time?) but current behavior has that
problem.  Heck, current behavior is often baffling to *me*.

The other thing which came out of this incident (and many user reports)
is the rather extreme opacity of our locking information, despite the
improvements of the last 2 versions.  However, I don't have a proposal
on how that should be fixed .... yet.

                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to