On 11.01.2011 23:51, Jeff Davis wrote:
> 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.
Yeah, I don't think it's a good idea to provide such a foot-gun.
Last time we discussed this there was the idea of creating a file in
$PGDATA, and removing read-permissions from it, so that it couldn't be
accidentally included in the backup. Even with that safeguard, it
doesn't feel very safe - a backup running as root or some other special
privileges might still be able to read it.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
