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