Re: [BUG] non archived WAL removed during production crash recovery

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: [BUG] non archived WAL removed during production crash recovery
Date: 2020-04-08 11:58:30
Message-ID: 20200408135830.25a8e2ef@firost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Wed, 8 Apr 2020 11:23:45 +0900
Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Tue, Apr 07, 2020 at 05:17:36PM +0200, Jehan-Guillaume de Rorthais wrote:
> > I'm not sure who would need this information before the WAL machinery is up,
> > but is it safe enough in your opinion for futur usage of
> > GetRecoveryState()? Do you think this information might be useful before
> > the WAL machinery is set? Current "user" (eg. restoreTwoPhaseData()) only
> > need to know if we are in recovery, whatever the reason.
>
> (I had this thread marked as something to look at, but could not.
> Sorry for the delay).

(no worries :))

> > src/test/recovery/t/011_crash_recovery.pl | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/test/recovery/t/011_crash_recovery.pl
> > b/src/test/recovery/t/011_crash_recovery.pl index ca6e92b50d..ce2e899891
> > 100644 --- a/src/test/recovery/t/011_crash_recovery.pl
> > +++ b/src/test/recovery/t/011_crash_recovery.pl
> > @@ -15,11 +15,17 @@ if ($Config{osname} eq 'MSWin32')
>
> May I ask why this new test is added to 011_crash_recovery.pl which is
> aimed at testing crash and redo, while we have 002_archiving.pl that
> is dedicated to archiving in a more general manner?

I thought it was a better place because the test happen during crash recovery.

In the meantime, while working on other tests related to $SUBJECT and the
current consensus, I was wondering if a new file would be a better place anyway.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hamid Akhtar 2020-04-08 12:15:40 Re: BUG #16351: PostgreSQL closing connection during requests with segmentation fault
Previous Message PG Bug reporting form 2020-04-08 08:55:34 BUG #16351: PostgreSQL closing connection during requests with segmentation fault

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-04-08 12:12:13 Re: WIP: WAL prefetch (another approach)
Previous Message Thomas Munro 2020-04-08 11:55:51 pgsql: Rationalize GetWalRcv{Write,Flush}RecPtr().