Re: Stronger safeguard for archive recovery not to miss data

Laurenz Albe <laurenz.albe@cybertec.at>

From: Laurenz Albe <laurenz.albe@cybertec.at>
To: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, 'Kyotaro Horiguchi' <horikyota.ntt@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-21T12:51:27Z
Lists: pgsql-hackers
On Thu, 2021-01-21 at 11:49 +0000, osumi.takamichi@fujitsu.com wrote:
> Adding a condition to check if "recovery_allow_data_corruption" is 'on' around the end of
> CheckRequiredParameterValues() sounds safer for me too, although
> implementing a new GUC parameter sounds bigger than what I expected at first.
> The default of the value should be 'off' to protect users from getting the corrupted server.
> Does everyone agree with this direction ?

I'd say that adding such a GUC is material for another patch, if we want it at all.

I think it is very unlikely that people will switch from "wal_level=replica" to
"minimal" and back very soon afterwards and also try to recover past such
a switch, which probably explains why nobody has complained about data corruption
generated that way.  To get the server to start with "wal_level=minimal", you must
set "archive_mode=off" and "max_wal_senders=0", and few people will do that and
still expect recovery to work.

My vote is that we should not have a GUC for such an unlikely event, and that
stopping recovery is good enough.

Yours,
Laurenz Albe




Commits

  1. Fix test added by commit 9de9294b0c.

  2. Stop archive recovery if WAL generated with wal_level=minimal is found.