Re: making relfilenodes 56 bits

On Thu, Sep 8, 2022 at 4:10 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:

> On a separate note, while reviewing the latest patch I see there is some risk of using the unflushed relfilenumber in GetNewRelFileNumber() function. Basically, in the current code, the flushing logic is tightly coupled with the logging new relfilenumber logic and that might not work with all the values of the VAR_RELNUMBER_NEW_XLOG_THRESHOLD. So the idea is we need to keep the flushing logic separate from the logging, I am working on the idea and I will post the patch soon.

I have fixed the issue, so now we will track nextRelFileNumber,
loggedRelFileNumber and flushedRelFileNumber. So whenever
nextRelFileNumber is just VAR_RELNUMBER_NEW_XLOG_THRESHOLD behind the
loggedRelFileNumber we will log VAR_RELNUMBER_PER_XLOG more
relfilenumbers. And whenever nextRelFileNumber reaches the
flushedRelFileNumber then we will do XlogFlush for WAL upto the last
loggedRelFileNumber. Ideally flushedRelFileNumber should always be
VAR_RELNUMBER_PER_XLOG number behind the loggedRelFileNumber so we can
avoid tracking the flushedRelFileNumber. But I feel keeping track of
the flushedRelFileNumber looks cleaner and easier to understand. For
more details refer to the code in GetNewRelFileNumber().

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com