Horton

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

Jehan-Guillaume de Rorthais <jgdr@dalibo.com>

View thread View on postgr.es
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: masao.fujii@oss.nttdata.com, pgsql-bugs@lists.postgresql.org, michael@paquier.xyz
Date: 2020-04-02T13:02:34Z
Lists: pgsql-bugs, pgsql-hackers 
On Thu, 02 Apr 2020 13:07:34 +0900 (JST)
Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:

> Sorry, it was quite ambiguous.
> 
> At Thu, 02 Apr 2020 13:04:43 +0900 (JST), Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote in 
> > At Wed, 1 Apr 2020 18:17:35 +0200, Jehan-Guillaume de Rorthais
> > <jgdr@dalibo.com> wrote in   
> > > Please, find in attachment a patch implementing this.  
> > 
> > The patch partially reintroduces the issue the patch have
> > fixed. Specifically a standby running a crash recovery wrongly marks a
> > WAL file as ".ready" if it is extant in pg_wal without accompanied by
> > .ready file.  
> 
> The patch partially reintroduces the issue the commit 78ea8b5daa have
> fixed. Specifically a standby running a crash recovery wrongly marks a
> WAL file as ".ready" if it is extant in pg_wal without accompanied by
> .ready file.

As far as I understand StartupXLOG(), NOT_IN_RECOVERY and IN_CRASH_RECOVERY are
only set for production clusters, not standby ones. So the following test
should never catch standby cluster as :

  (XLogArchivingActive() && inRecoveryState != IN_ARCHIVE_RECOVERY)

Forgive me if I'm wrong, but do I miss something?

Regards,

Commits

  1. Fix interpolation in test name.

  2. Add more TAP coverage for archive status with crash recovery of standbys

  3. Fix handling of WAL segments ready to be archived during crash recovery

  4. Fix WAL recycling on standbys depending on archive_mode