On Fri, Mar 03, 2023 at 01:38:38PM +0530, Bharath Rupireddy wrote: > On Wed, Mar 1, 2023 at 1:46 PM Michael Paquier <mich...@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
