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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
