Re: Does recovery write to backup_label ?

From: Andres Freund <andres(at)anarazel(dot)de>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Does recovery write to backup_label ?
Date: 2020-02-07 19:55:46
Message-ID: 20200207195546.jukct2n5eaxjhjbc@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-02-07 19:56:47 pg_basebackup and snapshots
Previous Message Andres Freund 2020-02-07 19:47:58 Re: logical decoding : exceeded maxAllocatedDescs for .spill files