There's a couple of items on the TODO page
(https://wiki.postgresql.org/wiki/Hot_Standby_TODO) that haven't been
discussed on-list:
> In normal operation, a few commands call ForceSyncCommit() to force non-async commit. Should ForceSyncCommit force an
XLogFlush()during recovery as well?
>
> * Simon says: No, why should it?
For the same reason we emit ForceSyncCommit() in normal operation. For
example, in DROP DATABASE, we delete all the files belonging to the
database, and then commit the transaction. If we crash after all the
files have been deleted but before the commit, you have an entry in
pg_database without any files. To minimize the window for that, we use
ForceSyncCommit() to rush the commit record to disk as quick as
possible. We have the same window during recovery, and forcing an
XLogFlush() (which updates minRecoveryPoint during recovery) would help
to keep it small.
This isn't really related to Hot Standby. If you set the PITR target
time/xid to between the XLOG_DBASE_DROP record and the COMMIT record,
you end up with a zombie pg_database entry.
> @Heikki: Why is error checking in KnownAssignedXidsRemove() #ifdef'd out??
It's explained in the comment:
/* XXX: This can still happen: If a transaction with a subtransaction* that haven't been reported yet aborts, and no
WALrecords have been* written using the subxid, the abort record will contain that subxid* and we haven't seen it
before.*/
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
