Greg Stark wrote: > 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?
I presume max_standby_delay would still apply, and we would only use the new mechanism where we would otherwise outright kill a query. > The bigger problem with this is that I don't see any way to tune this > to have a safe replica. Yeah, it's very opportunistic. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
