Simon Riggs wrote:
We were already assuming archive files were "OK to delete, if before". The whole of recovery already relies heavily on the alphabetic sorting property of WAL and associated filenames. Those filenames have been specifically documented as maintaining that sorted order for that reason. If somebody wanted to recover files in non-sorted order, then yes I would expect a few things to break - this aspect wouldn't be the most critical thing though.
I didn't suggest that alphabetical sorting property is a new assumption; it sure isn't. The new assumption is that you never call ReadRecord() for record 0002 before you call it for record 0001 (before initializing the checkPointCopy field from the checkpoint record, anyway).
I can imagine a future patch to do xlog file prefetching, for example, that breaks that assumption. Or falling back to the previous checkpoint as discussed. Or maybe you screwed up your recovery.conf, and try to use WAL files that belong to a different installation. The database won't start up, of course, because the checkpoint record isn't in the right place, but the damage has already been done because the recovery command deleted some files it shouldn't have.
Granted, none of those are particularly likely, but we should be extra careful when deleting files.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
