Greg Stark wrote:
> On Sat, Dec 12, 2009 at 3:06 PM, Simon Riggs <simon@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