On Sat, Dec 12, 2009 at 3:06 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > Anyone acquiring a lock on a table should check the latestRemovedXid for > the table and abort if their xmin is too old. This prevents new lockers > from accessing a cleaned relation immediately after we decide to abort > anyone looking at that table. (Anyone queuing for the existing locks > would be caught by this).
I fear given HOT pruning that this could mean no query can even get started against a busy table. It seems like you would have to start your transaction several times until you manage to get a lock on the busy table soon enough after taking the snapshot to not have missed any cleanups in the table. Or have I missed something that protects against that? The bigger problem with this is that I don't see any way to tune this to have a safe replica. In the current system you can set standby_max_delay to 0 or -1 or whatever to completely disable killing off valid queries on the replica. In this setup you're going ahead with cleanup records which may or may not be safe and then have no recourse if they turn out to conflict. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers