On Mon, May 13, 2019 at 10:37:35AM -0700, Andres Freund wrote: > Ugh, this is all such a mess. But, isn't this broken independently of > the smgrimmedsync() issue? In a basebackup case, the basebackup could > have included the main fork, but not the init fork, and the reverse. WAL > replay *solely* needs to be able to recover from that. At the very > least we'd have to do the cleanup step after becoming consistent, not > just before recovery even started.
Yes, the logic using smgrimmedsync() is race-prone and weaker than the index AMs in my opinion, even if the failure window is limited (I think that this is mentioned upthread a bit). What's actually the reason preventing us from delaying the checkpointer like the index AMs for the logging of heap init fork? The fact that the init heap fork is an empty page? -- Michael
signature.asc
Description: PGP signature
