On Tue, Dec 11, 2018 at 09:15:16AM -0500, David Steele wrote:
> It looks to me like the history file is written first, and then the
> .partial. But because we process WAL alphabetically the .partial ends
> up being pushed first.
Yes, that's right.
> The idea is to stake a claim to the timeline as quickly as possible so
> nobody else claims it. The pgarch_readyXlog() reads through all the
> files, so it would be easy to return the history files first, then the
> .partial, then the new timeline files, regardless of what order the
> .ready files were written in.
>
> The history file is also small, so it will be faster to copy and less
> subject to latency concerns. We want to reduce the window in which
> another potential primary can end up with a duplicate timeline.
Your arguments here are sensible, so +1 for changing pgarch_readyXlog so
as it gives priority to history files for archiving. It seems to me
that we should also be careful of ordering partial files and normal
segments, and perhaps consider backup history files as having the lower
level of priority.
>>> Another option would be to immediately archive the first WAL segment on
>>> timeline 2 and forgo the .partial file entirely. In this case the
>>> archiver will archive the 00000002.history file before
>>> 000000020000000100000001 and we avoid the race condition above. That
>>> also means we could recover A and promote without a conflict on the
>>> .partial. Or we could recover A along timeline 2.
>>
>> This breaks the definition of IsPartialXLogFileName() in
>> xlog_internal.h, and the current naming convention of using only dots as
>> field separators.
>
> Good point. Interesting that missing this didn't break any tests.
This means also that we may need more tests for that. For pg_receivewal
this could just be a check at the end of the last test for example.
>> Another more tricky problem is that this is
>> inconsistent with the way pg_receivewal.c behaves for non-completed
>> segments, which is a reason behind using .partial for the last partial
>> segment on the backend side as well. So this proposal makes things more
>> inconsistent.
>
> I think that we might need to apply the same logic to pg_receivewal.
I really don't think that it is a good idea to link a future timeline
within a segment which includes in its name a direct reference to its
current timeline. Also I don't buy much the argument that those
segments are a nuisance as well all the time. They may be for some
tools, however not for others depending on the archiving strategy
(distributed locations for example), and if they are a problem for your
deployments, why not just discarding them within the archive command and
be done with them?
--
Michael
