On Wed, Oct 13, 2021 at 10:58 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > On 2021-Oct-13, Amul Sul wrote: > > > I have one more question, regarding the need for other global > > variables i.e. abortedRecPtr. (Sorry for coming back after so long.) > > > > Instead of abortedRecPtr point, isn't enough to write > > overwrite-contrecord at XLogCtl->lastReplayedEndRecPtr? I think both > > are pointing to the same location then can't we use > > lastReplayedEndRecPtr instead of abortedRecPtr to write > > overwrite-contrecord and remove need of extra global variable, like > > attached? > > I'm a bit fuzzy on the difference "the end+1" and "the start of the next > record". Are they always the same? We do have XLogRecPtrToBytePos() > and XLogBytePosToEndRecPtr() to convert unadorned XLogRecPtr values to > "usable byte positions", which suggests to me that the proposed patch > may fail if end+1 is a page or segment boundary. >
Yes, you are correct, that could be a possible failure. How about calculating that from the lastReplayedEndRecPtr by converting it first to "usable byte positions" and then recalculating the record pointer from that, like attached? > The other difference is that abortedRecPtr is set if we fail to read a > record, but XLogCtl->lastReplayedEndRecPtr is set even if we read the > record successfully. So you'd have need a bool flag that the overwrite > contrecord record needs to be written. Your patch is using the fact > that missingContrecPtr is non-invalid as such a flag ... I can't see > anything wrong with that. So maybe your patch is okay in this aspect. > > > You might wonder why I am so concerned about the global variable. The > > reason is that I am working on another thread[1] where we are trying > > to club all the WAL write operations that happen at the end of > > StartupXLOG into a separate function. In the future, we might want to > > allow executing this function from other processes (e.g. > > Checkpointer). For that, we need to remove the dependency of those WAL > > write operations having on the global variables which are mostly valid > > in the startup process. > > Seems a fine goal. Thanks for looking at the patch. Regards, Amul
v2_remove-abortedRecPtr-global-variable.patch
Description: Binary data
