Alvaro Herrera <alvhe...@commandprompt.com> writes: > Sure. The problem is that we are allowing updated rows to be locked (and > locked rows to be updated). This means that we need to store extended > Xmax information in tuples that goes beyond mere locks, which is what we > were doing previously -- they may now have locks and updates simultaneously.
> (In the previous code, a multixact never meant an update, it always > signified only shared locks. After a crash, all backends that could > have been holding locks must necessarily be gone, so the multixact info > is not interesting and can be treated like the tuple is simply live.) Ugh. I had not been paying attention to what you were doing in this patch, and now that I read this I wish I had objected earlier. This seems like a horrid mess that's going to be unsustainable both from a complexity and a performance standpoint. The only reason multixacts were tolerable at all was that they had only one semantics. Changing it so that maybe a multixact represents an actual updater and maybe it doesn't is not sane. 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