Hi, On 2019-05-14 14:22:15 +0900, Michael Paquier wrote: > On Mon, May 13, 2019 at 09:33:52PM -0700, Andres Freund wrote: > > On 2019-05-14 13:23:28 +0900, Michael Paquier wrote: > >> What's actually the reason preventing us from delaying the > >> checkpointer like the index AMs for the logging of heap init fork? > > > > I'm not following. What do you mean by "delaying the checkpointer"? > > I mean what Robert has mentioned here: > https://www.postgresql.org/message-id/ca+tgmoz4twapckhf-szv-npxdxl40zcwm9pnfjzurvrgm2o...@mail.gmail.com
That's a proposal, not something we actually ended up though? That's what confuses me about your earlier paragraph: "like the index AMs"? Where are we doing that in index AMs? > And my gut tells me that he got that right, because we are discussing > about race conditions with crashes and checkpoints in-between calls to > smgrimmedsync() and log_newpage(). That could be invasive for > back-branches, but for HEAD this would make the whole init fork > handling saner. How would this protect against the issues I mentioned where recovery starts from an earlier checkpoint and the basebackup could pick up a random set of version of the different forks? I don't like the idea of expanding the use of delayChkpt further for common operations, if anything we ought to try to reduce it. But I also don't see how it'd actually fix the issues, so perhaps that's moot. Greetings, Andres Freund
