On Wed, 2010-08-25 at 14:10 -0400, Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > It's still not a very practical idea at least at first glance. It
> > would mean storing a variable sized list of columns somewhere that can
> > be consulted when the update happens. I don't know how the share lock
> > infrastructure works but I don't think it's obvious that there is such
> > a place.
>
> Yeah, there are all sorts of practical issues to be solved before this
> idea is more than a pipe dream; one being that the method for marking a
> row as locked involves setting its xmax, which is none too compatible
> with having somebody else actually update it. Maybe you could make it
> work by copying the xmax forward to the new version, but it seems
> ticklish.
That's the plan. Can't see a problem, but will let you know.
> However, minimizing the amount of state needed to determine whether an
> update is allowed would clearly help to surmount at least some of the
> practical problems, which is why I suggested piggybacking on the HOT
> logic.
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 propose to make RI checks use FOR KEY SHARE LOCK rather than FOR SHARE
LOCK. So we keep the semantics for share locking for explicit users,
just add a new flavour.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
