Simon Riggs wrote:
> 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.
Well, it's still in the repository.
> 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.
With a), you need to keep track of the seen VFI-in-progress records,
remember to expire the state at a shutdown record etc. And you have to
deal with the possibility that a checkpoint happens between the
VFI-in-progress record and the commit record; a recovery starting from
the checkpoint/running-xacts record must see both records or it will
release the locks prematurely.
b) seems much simpler to me.
> 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.
I's harmless to set a clog entry as committed twice, so you can treat
the 2nd commit record the same as a regular commit record.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
