From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Matsumura, Ryo" <matsumura(dot)ryo(at)jp(dot)fujitsu(dot)com> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Qestion about .partial WAL file |
Date: | 2019-04-11 03:55:43 |
Message-ID: | 20190411035543.GK2728@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 11, 2019 at 12:32:21AM +0000, Matsumura, Ryo wrote:
> I expected that the latest WAL segment file in old timeline is renamed with .partial suffix,
> but it's not renamed in the restarted standby.
Please note that the last partial segment is only generated on an
instance which has promoted. If you replug another standby into the
promoted standby, then this replugged standby will not generate a
.partial file, and it should not. What kind of behavior you think is
right and what did you expect?
> xlog.c says the following, but I didn't understand the bad situation.
>
> * the archive. It's physically present in the new file with new TLI,
> * but recovery won't look there when it's recovering to the older
> --> * timeline. On the other hand, if we archive the partial segment, and
> --> * the original server on that timeline is still running and archives
> --> * the completed version of the same segment later, it will fail. (We
> * used to do that in 9.4 and below, and it caused such problems).
If using archive_mode = on, then a promoted standby which archives WAL
segments in the same location as the primary may finish by creating a
conflict if the previous primary is still running after the standby
has been promoted, and that this previous primary is able to finish
the segment where WAL has forked.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-04-11 03:59:52 | Re: REINDEX CONCURRENTLY 2.0 |
Previous Message | David Rowley | 2019-04-11 03:34:30 | Re: Should we add GUCs to allow partition pruning to be disabled? |