From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
Subject: | Re: Allowing multiple concurrent base backups |
Date: | 2011-01-11 21:51:45 |
Message-ID: | 1294782705.25860.4.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2011-01-11 at 22:56 +0200, Heikki Linnakangas wrote:
> > 1. If it's a primary recovering from a crash, and there is a
> > backup_label file, and the WAL referenced in the backup_label exists,
> > then it does a bunch of extra work during recovery; and
> > 2. In the same situation, if the WAL referenced in the backup_label
> > does not exist, then it PANICs with a HINT to tell you to remove the
> > backup_label.
> >
> > Is this an opportunity to solve these problems and simplify the code?
>
> It won't change the situation for pg_start_backup(), but with the patch
> the base backups done via streaming won't have those issues, because
> backup_label is not created (with that name) in the master.
Do you think we should change the backup protocol for normal base
backups to try to fix this? Or do you think that the simplicity of
unrestricted file copy is worth these problems?
We could probably make some fairly minor changes, like making a file on
the primary and telling users to exclude it from any base backup. The
danger, of course, is that they do copy it, and their backup is
compromised.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-11 22:06:34 | Re: Allowing multiple concurrent base backups |
Previous Message | Euler Taveira de Oliveira | 2011-01-11 21:34:17 | Re: pgbench to the MAXINT |