Re: Hot Standby, deferred conflict resolution for cleanup records (v2)

On Sat, Dec 12, 2009 at 3:06 PM, Simon Riggs <simon(at)2ndquadrant(dot)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