Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
>> What I was complaining/suggesting is that we should make what you did to
>> actually work, because it's a lot simpler. And as Jonah pointed out,
>> we'd need to inhibit checkpoints between pg_start_backup() and
>> pg_stop_backup() to make it work.
>
> I don't think that follows --- what you'd need is to prevent the
> checkpoints from removing/recycling old WAL files, but you can still
> allow a checkpoint to occur. Any subsequent recovery from the backup
> would need to replay from the checkpoint identified by the backup label
> file anyway.
I was thinking that the restore would be a normal non-PITR recovery, but
if we do it as a PITR restore, that's true.
> Whether it's a good idea or not is a bit debatable though. I'm
> concerned about the WAL partition filling up (--> PANIC), especially
> if you forget to pg_stop_backup after getting your backup.
Yep, that would suck. We already have that problem if you set up
continuous archiving, and archive_command starts failing, don't we?
As a simple safeguard, we could have user-settable max. number of
segments, and give up on the backup after that. Though failing the
backup isn't nice either..
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
