On Thu, 2010-02-18 at 14:17 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Thu, 2010-02-18 at 14:23 +0200, Heikki Linnakangas wrote:
> >> A straightforward way to fix that is to WAL-log the real xid in the
> >> XLOG_BTREE_DELETE_PAGE records, instead of resetting it to
> >> FrozenTransactionId.
>
> > An even simpler way would be to reset the value to latestCompletedXid
> > during btree_xlog_delete_page(). That touches less code. I doubt it will
> > make much difference to conflict recovery, since if pages are being
> > deleted then btree delete records are likely to be frequent and will
> > have already killed long running queries.
>
> I'm a bit concerned about XID wraparound if the value doesn't get reset
> to FrozenTransactionId. There's no guarantee the page will get reused
> promptly ...
I'd be very interested for you to have a look at Hot Standby from a
transaction wraparound perspective. There was some code in there to
handle anti-wraparound in RecordKnownAssignedTransactionId() but it was
removed, though I'm a little hazy on that myself. You've got the best
nose for corner cases and risks.
In this case, I don't see any problem. The xid after recovery will be a
same or higher value than if the crash had never taken place, so I can't
see any risk that isn't already addressed.
Since we now have to handle cases where blocks have been touched in
pre-9.0 code and are in a state they could never get into in 9.0, we do
still have to handle a value of btpo.xact == FrozenTransactionId. I will
add a special case to the handling of XLOG_BTREE_REUSE_PAGE records also
to allow for that.
Any similar theoretical issues would be most welcome if reported.
-- Simon Riggs www.2ndQuadrant.com
