Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves) - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)
Date
Msg-id CAB7nPqQFVdooVWfW0-0qhw-TqbeDg88w1x5kqsvjUArJGz-bHg@mail.gmail.com
Whole thread
In response to Re: BUG: *FF WALs under 9.2 (WAS: .ready files appearing on slaves)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers


On Wed, Oct 8, 2014 at 11:38 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
On 10/08/2014 04:59 PM, Fujii Masao wrote:
On Wed, Oct 8, 2014 at 6:54 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
Instead of creating any .done files during recovery, we could scan pg_xlog
at promotion, and create a .done file for every WAL segment that's present
at that point. That would be more robust. And then apply your patch, to
recycle old segments during archive recovery, ignoring .done files.

What happens if a user shutdowns the standby, removes recovery.conf and
starts the server as the master?

Um, that's not a safe thing to do anyway, is it?
That's not safe as it bypasses all the consistency checks of promotion. Now, it is also something that repmgr for example does as far as I recall to do a node "promotion". What if we simply document the problem properly then? The apparition of those phantom WAL files is more scary than a user or a utility that does a promotion with a server restart. Not to mention as well that users as free to add themselves files to pg_xlog.
--
Michael

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: UPSERT wiki page, and SQL MERGE syntax
Next
From: Michael Paquier
Date:
Subject: Re: Add CREATE support to event triggers