VACUUM FULL does a peculiar hack: once it's done moving tuples, and
before it truncates the relation, it calls RecordTransactionCommit to
mark the transaction as committed in clog and WAL, but the transaction
is still kept open in proc array. After it's done with truncating and
other cleanup, normal transaction commit performs
RecordTransactionCommit again as part of normal commit processing.
That causes some headaches for Hot Standby, ie. it needs to know to not
release locks yet when it sees the first commit record. At the moment,
it simply ignores the first commit record, but that's very dangerous. If
failover happens after the standby has seen the truncation record, but
not the 2nd commit record for the transaction, all data moved from the
truncated part will lost.
I'm sure that's fixable, but I believe we're quite committed to removing
VACUUM FULL altogether in this release. If that's going to happen, I can
just remove all the VACUUM FULL related code from the Hot Standby patch
now and not spend any more time on it.
I'm a bit hesitent to do that because that basically leaves me in the
exact situation I said before I wanted to avoid: If I commit Hot Standby
without dealing with VACUUM FULL, and no-one gets around to remove
VACUUM FULL (and more importantly, provide some replacement for it), I
will be forced to do it myself or fix Hot Standby to work with it after
all. I might be involved in the VACUUM FULLectomy anyway, but I don't
want to be pushed against the wall on it.
So I guess what I'm asking is: Does anyone see any show-stoppers in
removing VACUUM FULL, and does anyone want to step up to the plate and
promise to do it before release?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
