Re: Handing off SLRU fsyncs to the checkpointer
От | Thomas Munro |
---|---|
Тема | Re: Handing off SLRU fsyncs to the checkpointer |
Дата | |
Msg-id | CA+hUKG+55CPM0p76WyjNe==d09J8FbcEV99gjGbZf_APF446Cw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Handing off SLRU fsyncs to the checkpointer (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Handing off SLRU fsyncs to the checkpointer
|
Список | pgsql-hackers |
On Mon, Sep 21, 2020 at 2:19 PM Thomas Munro <thomas.munro@gmail.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().
В списке pgsql-hackers по дате отправления: