On Fri, Sep 9, 2011 at 5:31 PM, Alvaro Herrera
<alvherre@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