On Wed, 2010-08-25 at 14:10 -0400, Tom Lane wrote: > Greg Stark <gsst...@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.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
