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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers