On 2019-Dec-13, Kyotaro Horiguchi wrote:
> At Thu, 12 Dec 2019 22:50:20 +0000, "Bossart, Nathan" <bossartn@amazon.com> wrote in
> > The crux of the issue seems to be that XLogWrite() does not wait for
> > the entire record to be written to disk before creating the ".ready"
> > file. Instead, it just waits for the last page of the segment to be
> > written before notifying the archiver. If PostgreSQL crashes before
> > it is able to write the rest of the record, it will end up reusing the
> > ".ready" segment at the end of crash recovery. In the meantime, the
> > archiver process may have already processed the old version of the
> > segment.
>
> Year, that can happen if the server restarted after the crash.
... which is the normal way to run things, no?
> > servers after the primary server has crashed because it ran out of
> > disk space.
>
> In the first place, it's quite bad to set restart_after_crash to on,
> or just restart crashed master in replication set.
Why is it bad? It's the default value.
> The standby can be incosistent at the time of master crash, so it
> should be fixed using pg_rewind or should be recreated from a base
> backup.
Surely the master will just come up and replay its WAL, and there should
be no inconsistency.
You seem to be thinking that a standby is promoted immediately on crash
of the master, but this is not a given.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services