Re: Handing off SLRU fsyncs to the checkpointer

On Tue, Sep 22, 2020 at 9:08 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Mon, Sep 21, 2020 at 2:19 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > While scanning for comments and identifier names that needed updating,
> > I realised that this patch changed the behaviour of the ShutdownXXX()
> > functions, since they currently flush the SLRUs but are not followed
> > by a checkpoint. I'm not entirely sure I understand the logic of
> > that, but it wasn't my intention to change it. So here's a version
> > that converts the existing fsync_fname() to fsync_fname_recurse() to
>
> Bleugh, that was probably a bad idea, it's too expensive. But it
> forces me to ask the question: *why* do we need to call
> Shutdown{CLOG,CommitTS,SUBTRANS, MultiXact}() after a creating a
> shutdown checkpoint? I wondered if this might date from before the
> WAL, but I see that the pattern was introduced when the CLOG was moved
> out of shared buffers into a proto-SLRU in ancient commit 2589735da08,
> but even in that commit the preceding CreateCheckPoint() call included
> a call to CheckPointCLOG().

I complained about the apparently missing multixact fsync in a new
thread, because if I'm right about that it requires a back-patchable
fix.

As for the ShutdownXXX() functions, I haven't yet come up with any
reason for this code to exist. Emboldened by a colleague's inability
to explain to me what that code is doing for us, here is a new version
that just rips it all out.