pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: masao.fujii@oss.nttdata.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: [BUG] non archived WAL removed during production crash recovery
Date: Mon, 20 Apr 2020 14:22:35 +0200
Message-ID: <20200420142235.1536a73b@firost> (raw)
In-Reply-To: <20200420073444.GA77439@paquier.xyz>
References: <20200417065043.GC350229@paquier.xyz>
	<20200417153304.01a226cc@firost>
	<20200418092611.GD350229@paquier.xyz>
	<20200420.160231.719176619682386260.horikyota.ntt@gmail.com>
	<20200420073444.GA77439@paquier.xyz>

On Mon, 20 Apr 2020 16:34:44 +0900
Michael Paquier <michael@paquier.xyz> wrote:
[...]
> > By the way I noticed that RecoveryState is exactly a subset of
> > DBState.  And changes of SharedRecoveryState happens side-by-side with
> > ControlFileData->state in most places.  Coundn't we just usee
> > ControlFile->state instead of SharedRecoveryState?
> 
> I actually found confusing to use the same thing, because then the
> reader would thing that SharedRecoveryState could be set to more
> values but we don't want that.

I thought about this while studying various possible fix. 

https://www.postgresql.org/message-id/flat/20200401181735.11100908%40firost#6192afba4e4549b8d9bac031...

The problem is that we would have to read the controldata file each time we
wonder if a segment should be archived/removed. Moreover, the controldata
file might not be in sync quickly enough with the real state for some other
code path or futur needs.

[...]
> Attached is an updated patch, where I tweaked more comments.
> 
> Jehan-Guillaume, who is your colleague who found originally about this
> problem?  We should credit him in the commit message.

Indeed, Benoît Lobréau reported this behavior to me.

Regards,





view thread (67+ messages)  latest in thread

Message-ID: <20200420142235.1536a73b@firost>
Permalink:  ../20200420142235.1536a73b@firost/
Also on:    postgresql.org/message-id/20200420142235.1536a73b@firost

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: jgdr@dalibo.com, michael@paquier.xyz, horikyota.ntt@gmail.com, masao.fujii@oss.nttdata.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: [BUG] non archived WAL removed during production crash recovery
  In-Reply-To: <20200420142235.1536a73b@firost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox