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-25 08:19:54
Message-ID: OSBPR01MB48887EFFCA39FA9B1DBAFB0FEDBD0@OSBPR01MB4888.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

On Monday, January 25, 2021 5:13 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> On Thu, 2021-01-21 at 15:30 +0100, I wrote:
> > On Thu, 2021-01-21 at 13:09 +0000, osumi(dot)takamichi(at)fujitsu(dot)com wrote:
> >
> > > > 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.
> >
> > Well, that's just my opinion.
> >
> > Fujii Masao seemed to disagree with the patch, and his voice carries weight.
>
> I think you should pst another patch where the second, now superfluous, error
> message is removed.
Updated. This patch showed no failure during regression tests
and has been aligned by pgindent.

Best Regards,
Takamichi Osumi

Attachment Content-Type Size
stronger_safeguard_for_archive_recovery_v04.patch application/octet-stream 7.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message k.jamison@fujitsu.com 2021-01-25 08:22:33 RE: libpq debug log
Previous Message Masahiko Sawada 2021-01-25 08:19:43 Re: New IndexAM API controlling index vacuum strategies