Re: [HACKERS] Unlogged tables cleanup
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Unlogged tables cleanup |
Дата | |
Msg-id | 20190514061953.pkdga4eps5znksuj@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Unlogged tables cleanup (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [HACKERS] Unlogged tables cleanup
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: