|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Michael Paquier <michael(at)paquier(dot)xyz>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] Unlogged tables cleanup|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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:
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.
|Next Message||Yugo Nagata||2019-05-14 06:46:48||Re: Implementing Incremental View Maintenance|
|Previous Message||Kyotaro HORIGUCHI||2019-05-14 06:18:07||Re: Tab completion for CREATE TYPE|