Re: Simplify standby state machine a bit in WaitForWALToBecomeAvailable() - Mailing list pgsql-hackers

On Fri, Mar 03, 2023 at 01:38:38PM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 1, 2023 at 1:46 PM Michael Paquier <michael@paquier.xyz> wrote:
>> Well, did you notice 4d894b41?  It introduced this change:
>>
>> -               readFile = XLogFileReadAnyTLI(readSegNo, DEBUG2, currentSource);
>> +               readFile = XLogFileReadAnyTLI(readSegNo, DEBUG2,
>> +                       currentSource == XLOG_FROM_ARCHIVE ? XLOG_FROM_ANY :
>> +                                        currentSource);
>>
>> And this patch basically undoes that, meaning that we would basically
>> look at the archives first for all the expected TLIs, but only if no
>> files were found in pg_wal/.
>>
>> The change is subtle, see XLogFileReadAnyTLI().  On HEAD we go through
>> each timeline listed and check both archives and then pg_wal/ after
>> the last source that failed was the archives.  The patch does
>> something different: it checks all the timelines for the archives,
>> then all the timelines in pg_wal/ with two separate calls to
>> XLogFileReadAnyTLI().
> 
> Thanks. Yeah, the patch proposed here just reverts that commit [1]
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=4d894b41cd12179b710526eba9dc62c2b99abc4d.
> 
> That commit fixes an issue - "If there is a WAL segment with same ID
> but different TLI present in both the WAL archive and pg_xlog, prefer
> the one with higher TLI.".

Given both Bharath and I missed this, perhaps we should add a comment about
this behavior.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com