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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
