| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 |
| Date: | 2019-05-14 04:23:28 |
| Message-ID: | 20190514042328.GK1418@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 13, 2019 at 10:37:35AM -0700, Andres Freund wrote:
> Ugh, this is all such a mess. But, isn't this broken independently of
> the smgrimmedsync() issue? In a basebackup case, the basebackup could
> have included the main fork, but not the init fork, and the reverse. WAL
> replay *solely* needs to be able to recover from that. At the very
> least we'd have to do the cleanup step after becoming consistent, not
> just before recovery even started.
Yes, the logic using smgrimmedsync() is race-prone and weaker than the
index AMs in my opinion, even if the failure window is limited (I
think that this is mentioned upthread a bit). What's actually the
reason preventing us from delaying the checkpointer like the index AMs
for the logging of heap init fork? The fact that the init heap fork
is an empty page?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2019-05-14 04:23:36 | Re: [HACKERS] advanced partition matching algorithm for partition-wise join |
| Previous Message | Michael Paquier | 2019-05-14 04:15:04 | Re: [HACKERS] Unlogged tables cleanup |