From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(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-14 15:55:56 |
Message-ID: | 575537088c5db741832eff4b24d3415a339cb884.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2020-12-08 at 03:08 +0000, osumi(dot)takamichi(at)fujitsu(dot)com wrote:
> On Thursday, November 26, 2020 4:29 PM
> Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > 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
> > > The attached patch is intended to prevent a scenario that archive
> > > recovery hits WALs which come from wal_level=minimal and the server
> > > continues to work, which was discussed in the thread of [1].
> >
> > Perhaps we need the TAP test that conducts the above steps.
>
> I added the TAP tests to reproduce and share the result,
> using the case of 6-(1) described above.
> Here, I created a new file for it because the purposes of other files in
> src/recovery didn't match the purpose of my TAP tests perfectly.
> If you are dubious about this idea, please have a look at the comments
> in each file.
>
> When the attached patch is applied,
> my TAP tests are executed like other ones like below.
>
> t/018_wal_optimize.pl ................ ok
> t/019_replslot_limit.pl .............. ok
> t/020_archive_status.pl .............. ok
> t/021_row_visibility.pl .............. ok
> t/022_archive_recovery.pl ............ ok
> All tests successful.
>
> Also, I confirmed that there's no regression by make check-world.
> Any comments ?
The patch applies and passes regression tests, as well as the new TAP test.
I think this should be backpatched, since it fixes a bug.
I am not quite happy with the message:
FATAL: WAL was generated with wal_level=minimal, data may be missing
HINT: This happens if you temporarily set wal_level=minimal without taking a new base backup.
This sounds too harmless to me and doesn't give the user a clue
what would be the best way to proceed.
Suggestion:
FATAL: WAL was generated with wal_level=minimal, cannot continue recovering
DETAIL: This happens if you temporarily set wal_level=minimal on the primary server.
HINT: Create a new standby from a new base backup after setting wal_level=replica.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2021-01-14 16:22:17 | NOT VALID for Unique Indexes |
Previous Message | Tom Lane | 2021-01-14 15:42:54 | Re: pg_preadv() and pg_pwritev() |