On Fri, 2009-12-04 at 11:22 +0200, Heikki Linnakangas wrote:
> > 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.
I don't see we need either of those, with the solution below.
ISTM premature to remove all traces of VF from code. We may yet need it
for some reason, especially if doing so creates complex dependencies on
important features.
> > 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.
So modified proposal looks like this
1. (In normal running) Provide information to HS so it can identify VF
commit records.
Implement in code either
a) Just before we issue the first VFI commit we send a new type of WAL
message to indicate VFI-in-progress, including the xid.
b) Alter the API of RecordTransactionCommit(), and send the info within
the commit record. This was pretty much how we did that before.
I prefer (a) now because the ugliness is better isolated.
2. (In HS recovery) When we see first commit record for the VF xid we
commit the transaction in clog, yet maintain locks and KnownAssigned
xids
3. (In HS recovery) When we see second commit record for the VF xid we
skip clog updates but then perform remaining parts of commit.
Conceptually this splits a VF commit into two parts.
-- Simon Riggs www.2ndQuadrant.com
