Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> I think we could get away without the backup history file altogether.
>
> Hmmm ... actually I was confusing these with timeline history files,
> which are definitely not something we can drop. You might be right
> that the backup history file could be part of WAL instead. On the other
> hand, it's quite comforting that the history file is plain ASCII and can
> be examined without any special tools. I'm -1 for removing it, even
> if we decide to duplicate the info in a WAL record.
Ok. How about writing the history file in pg_stop_backup() for
informational purposes only. Ie. never read it, but rely on the WAL
records instead.
I just realized that the current history file fails to recognize this
scenario:
1. pg_start_backup()
2. cp -a $PGDATA data-backup
3. create data-backup/recovery.conf
4. postmaster -D data-backup
That is, starting postmaster on a data directory, without ever calling
pg_stop_backup(). Because pg_stop_backup() was not called, the history
file is not there, and recovery won't complain about not reaching the
safe starting point.
That is of course a case of "don't do that!", but perhaps we should
refuse to start up if the backup history file is not found? At least in
the WAL-based approach, I think we should refuse to start up if we don't
see the pg_stop_backup WAL record.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com