|From:||Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org|
|Subject:||Re: [BUG] non archived WAL removed during production crash recovery|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, 22 Apr 2020 16:32:23 +0900
Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Wed, Apr 22, 2020 at 10:19:35AM +0900, Michael Paquier wrote:
> > You are right here. The restriction can be removed, and I have
> > checked that the test from v8 is able to pass on my Windows dev VM.
> Attached are versions for each branch down to 9.5. While working on
> the backpatch, I have not found major conflicts except one thing:
> up to 10, Postgres does WAL segment recycling after two completed
> checkpoints, and the 8th test of the script relies on the behavior of
> 11~ of one completed checkpoint (first .ready file present in the cold
> backup but removed removed from $standby1). I have taken the simplest
> approach to fix the test by checking that the .ready file actually
> exists, while the rest of the test remains the same.
This test seems useless to me. It should either be removed or patched to test
the signal has been removed after a second restartpoint.
Please, find in attachment a patch for 9.6 implementing this. If it seems
reasonable to you, I can create the backpatch to 9.5.
> It is worth noting that for 9.5 and 9.6 the test had compatibility
> issues with the renaming of pg_xlog to pg_wal, including paths and
> functions. The calls to poll_query_until() also needed tweaks, but
> I got the tests to work.
Thanks for the backpatching work!
|Next Message||Jehan-Guillaume de Rorthais||2020-04-22 16:17:17||Re: [BUG] non archived WAL removed during production crash recovery|
|Previous Message||John Muehlhausen||2020-04-22 15:38:11||Re: NOTIFY in multi-statement PQexec() not sent outside of transaction|
|Next Message||Erik Rijkers||2020-04-22 16:01:23||Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions|
|Previous Message||Andres Freund||2020-04-22 15:57:00||Re: Concurrency bug in amcheck|