Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
