On 12/13/18 7:15 PM, Michael Paquier wrote:
> On Thu, Dec 13, 2018 at 11:53:53AM -0500, David Steele wrote:
>> I also think we should consider back-patching this change. It's hard to
>> imagine that archive commands would have trouble with this reordering
>> and the current ordering causes real pain in HA clusters.
>
> I would like to hear opinion from other though if we should consider
> that as an improvement or an actual bug fix. Changing the order of the
> files to map with what the startup process does when promoting does not
> sound like a bug fix to me, still this is not really invasive, so we
> could really consider it worth back-patching to reduce common pain from
> users when it comes to timeline handling.
I think an argument can be made that it is a bug (ish). Postgres
generates the files in one order, and they get archived in a different
order.
>> - if (!found)
>> + /* Is this a history file? */
>> + bool history = basenamelen >= sizeof(".history") &&
>> + strcmp(rlde->d_name + (basenamelen - sizeof(".history") + 1),
>> + ".history.ready") == 0;
>
> Or you could just use IsTLHistoryFileName here?
We'd have to truncate .ready off the string to make that work, which
seems easy enough. Is that what you were thinking?
One thing to consider is the check above is more efficient than
IsTLHistoryFileName() and it potentially gets run a lot.
> If one wants to simply check this code, you can just create dummy orphan
> files in archive_status and see in which order they get removed.
Seems awfully racy. Are there currently any tests like this for the
archiver that I can look at extending?
Regards,
--
-David
david@pgmasters.net
