On Fri, Sep 9, 2011 at 5:31 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > [ multixact complexity ]
I wonder if it's a mistake to be thinking about solving this problem by extending the MultiXact mechanism. Pushing xmax out-of-line so that we have room to store tuple information seems expensive, especially because there's no convenient way to undo it once the locks are old enough not to be interesting any more. The current system works because we never need both pieces of information at the same time, but that's not going to be true any more. I'm wondering if it would be possible to modify the main lock manager, or create a special-purpose tuple lock manager, to record all tuple locks, both awaited and granted. You'd need to make sure that if there were more than a few locks the information could spill to disk somehow, and you'd also need to make sure that you didn't pull that information in from disk more often than necessary - i.e. you should try to keep enough summary info in memory to determine whether there *might* be a conflicting lock that spilled out, so that you only need to go examine the spilled data if there's a possibility that you might find something interesting there. A system like this would make it possible to clean up all the lock entries at transaction end, which would avoid a lot of the complexity you mention. On the other hand, it's clearly not simple, either, and I haven't thought through all the details... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
