RE: Stronger safeguard for archive recovery not to miss data

From: "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>
To: 'Laurenz Albe' <laurenz(dot)albe(at)cybertec(dot)at>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Stronger safeguard for archive recovery not to miss data
Date: 2021-01-21 13:09:26
Message-ID: OSBPR01MB488828C96A86961D6B84C29AEDA10@OSBPR01MB4888.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, Laurenz

On Thursday, January 21, 2021 9:51 PM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> On Thu, 2021-01-21 at 11:49 +0000, osumi(dot)takamichi(at)fujitsu(dot)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.
OK. You meant another different patch.

> 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.
Yeah, the possibility is low of course.

> My vote is that we should not have a GUC for such an unlikely event, and that
> stopping recovery is good enough.
OK. IIUC, my current patch for this fix doesn't need to be changed or withdrawn.
Thank you for your explanation.

Best Regards,
Takamichi Osumi

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2021-01-21 13:11:52 Re: Boundary value check in lazy_tid_reaped()
Previous Message Laurenz Albe 2021-01-21 12:51:27 Re: Stronger safeguard for archive recovery not to miss data