Re: Does recovery write to backup_label ?

From: David Steele <david(at)pgmasters(dot)net>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Does recovery write to backup_label ?
Date: 2020-02-10 04:53:47
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2/7/20 8:06 PM, Fujii Masao wrote:
> On Sat, Feb 8, 2020 at 5:05 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>> On 2/7/20 2:55 PM, Andres Freund wrote:
>>>> If the file needs to have 0600 permissions, should there be
>>>> a note in the nonexclusive-mode backup docs to say so?
>>> I'm not convinced that that's useful. The default is that everything
>>> needs to be writable by postgres. The exceptions should be noted if
>>> anything, not the default.
> +1


In theory it would be more secure to only allow rename, but since
Postgres can overwrite any other file in the cluster I don't see much
value in making an exception for this file.

>> Could this arguably be a special case, as most things in the datadir
>> are put there by postgres, but the backup_label is now to be put there
>> (and not even 'there' there, but added as a final step only to a
>> 'backup-copy-of-there' there) by the poor schmuck who reads the
>> non-exclusive backup docs as saying "retrieve this content from
>> pg_stop_backup() and preserve in a file named backup_label" and can't
>> think of any obvious reason to put write permission on a file
>> that preserves immutable history in a backup?
> I have no strong objection to add more note about permissions
> of the files that the users put in the data directory. If we really
> do that, it'd be better to note about not only backup_label
> but also other files like tablespace_map, recovery.signal,
> promotion trigger file, etc.

More documentation seems like a good idea, especially since
non-exclusive backup requires the app to choose/set permissions.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo NAGATA 2020-02-10 04:58:54 Re: Implementing Incremental View Maintenance
Previous Message Craig Ringer 2020-02-10 04:53:11 Re: Is custom MemoryContext prohibited?