Simon Riggs wrote:
> I've just reviewed the VACUUM FULL patch to see if it does all we need
> it to do, i.e. does the removal of HS code match the new VF patch.
Oh, good!
> My answer is it doesn't, we will still have the problem noted above for
> catalog tables. So we still have a must-fix issue for HS, though that is
> no barrier to the new VF patch.
I think the VACUUM FULL patch will have to address that. Either with the
flat-file approach Tom suggested, or by disallowing VACUUM FULL for
catalog tables altogether, requiring you to use the to-be-written online
tool that uses dummy UPDATEs to move tuples.
> Requirement is that
>
> * we ignore first commit, since it has an identical xid to second
> commit, so requires a special case to avoid breaking other checks
>
> * we musn't truncate until we are certain transaction completes,
> otherwise we will have a data loss situation (isolated to this
> particular case only)
>
> Proposal:
>
> * (In normal running) Just before we issue the first VFI commit we send
> a new type of WAL message to indicate VFI-in-progress, including the xid
>
> * (In HS recovery) When we see first commit record for the VF xid we
> ignore it, as we did in the original patch
>
> * (In HS recovery) When we see relation truncate for the xid we ignore
> it for now, but defer until after the second commit is processed
>
> It ain't that great, but it means all of the "hack" is isolated to
> specific HS-only code, which can be turned off if required.
Could you just mark the transaction as committed when you see the 1st
commit record, but leave the XID in the known-assigned list and not
release locks? That would emulate pretty closely what happens in the master.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com