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: '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: 2020-11-26 07:51:32
Message-ID: OSBPR01MB48881C0B250FF1E4B35C761AEDF90@OSBPR01MB4888.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, Horiguchi-San

On Thursday, Nov 26, 2020 4:29 PM Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
> At Thu, 26 Nov 2020 07:18:39 +0000, "osumi(dot)takamichi(at)fujitsu(dot)com"
> <osumi(dot)takamichi(at)fujitsu(dot)com> wrote in
> > In order to test this fix, what I did is
> > 1 - get a base backup during wal_level is replica
> > 2 - stop the server and change the wal_level from replica to minimal
> > 3 - restart the server(to generate XLOG_PARAMETER_CHANGE)
> > 4 - stop the server and make the wal_level back to replica
> > 5 - start the server again
> > 6 - execute archive recoveries in both cases
> > (1) by editing the postgresql.conf and
> > touching recovery.signal in the base backup from 1th step
> > (2) by making a replica with standby.signal
> > * During wal_level is replica, I enabled archive_mode in this test.
> >
> Perhaps we need the TAP test that conducts the above steps.
It really makes sense that it's better to show the procedures
about how to reproduce the flow.
Thanks for your advice.

Best,
Takamichi Osumi

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-11-26 07:53:04 Re: walsender bug: stuck during shutdown
Previous Message Pavel Stehule 2020-11-26 07:48:48 Re: [patch] [doc] Minor variable related cleanup and rewording of plpgsql docs