Re: Does recovery write to backup_label ? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Does recovery write to backup_label ?
Date
Msg-id 20200207195546.jukct2n5eaxjhjbc@alap3.anarazel.de
Whole thread Raw
In response to Does recovery write to backup_label ?  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: Does recovery write to backup_label ?
List pgsql-hackers
Hi,

On 2020-02-07 11:08:48 -0500, Chapman Flack wrote:
> Just saw this in a PG 11.6 cluster starting a recovery:
> 
> 2020-02-07 10:45:40 EST FATAL:  42501: could not open file
> "backup_label": Permission denied
> 2020-02-07 10:45:40 EST LOCATION:  fsync_fname_ext, fd.c:3531

Well, we generally assume that files in the data directory are writable,
with a very few exceptions. And we do need to be able rename
backup_label to backup_label.old. Which strictly speaking doesn't
require write permissions on the file - but I assume that's what
triggers the issue here. There's IIRC platforms that don't like fsyncing
files with a O_RDONLY fd, so if we want to rename safely (which entails
fsyncing beforehand), we don't have much choice.


> I had assumed the label file would be treated as readonly
> during recovery.

It is IIRC documented that it does get renamed...

> 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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Next
From: Stephen Frost
Date:
Subject: pg_basebackup and snapshots