RE: Stronger safeguard for archive recovery not to miss data - Mailing list pgsql-hackers

From osumi.takamichi@fujitsu.com
Subject RE: Stronger safeguard for archive recovery not to miss data
Date
Msg-id OSBPR01MB488828C96A86961D6B84C29AEDA10@OSBPR01MB4888.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Stronger safeguard for archive recovery not to miss data  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Stronger safeguard for archive recovery not to miss data  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
Hi, Laurenz


On Thursday, January 21, 2021 9:51 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> 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.
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

pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: Stronger safeguard for archive recovery not to miss data
Next
From: Masahiko Sawada
Date:
Subject: Re: Boundary value check in lazy_tid_reaped()