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-nPxDXL40zCwm9pNFJZURvRgm2oJzQ@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
