On Thu, Jan 28, 2021 at 7:17 AM Amul Sul <sula...@gmail.com> wrote: > I am still on this. The things that worried me here are the wal records > sequence > being written in the startup process -- UpdateFullPageWrites() generate record > just before the recovery check-point record and XLogReportParameters() just > after that but before any other backend could write any wal record. We might > also need to follow the same sequence while changing the system to read-write.
I was able to chat with Andres about this topic for a while today and he made some proposals which seemed pretty good to me. I can't promise that what I'm about to write is an entirely faithful representation of what he said, but hopefully it's not so far off that he gets mad at me or something. 1. If the server starts up and is read-only and ArchiveRecoveryRequested, clear the read-only state in memory and also in the control file, log a message saying that this has been done, and proceed. This makes some other cases simpler to deal with. 2. Create a new function with a name like XLogAcceptWrites(). Move the following things from StartupXLOG() into that function: (1) the call to UpdateFullPageWrites(), (2) the following block of code that does either CreateEndOfRecoveryRecord() or RequestCheckpoint() or CreateCheckPoint(), (3) the next block of code that runs recovery_end_command, (4) the call to XLogReportParameters(), and (5) the call to CompleteCommitTsInitialization(). Call the new function from the place where we now call XLogReportParameters(). This would mean that (1)-(3) happen later than they do now, which might require some adjustments. 3. If the system is starting up read only (and the read-only state didn't get cleared because of #1 above) then don't call XLogAcceptWrites() at the end of StartupXLOG() and instead have the checkpointer do it later when the system is going read-write for the first time. -- Robert Haas EDB: http://www.enterprisedb.com
