Re: [HACKERS] Unlogged tables cleanup

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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-27 02:11:24
Message-ID: 20190527021124.GE1963@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 23, 2019 at 09:14:59AM -0400, Robert Haas wrote:
> Suppose we create an unlogged table and then crash. The main fork
> makes it to disk, and the init fork does not. Before WAL replay, we
> remove any main forks that have init forks, but because the init fork
> was lost, that does not happen. Recovery recreates the init fork.
> After WAL replay, we try to copy_file() each _init fork to the
> corresponding main fork. That fails, because copy_file() expects to be
> able to create the target file, and here it can't do that because it
> already exists.

Ah, sorry. Now I understand your point. I got your previous message
wrong as I thought about the fact that init forks are logged, hence
after a crash you should still have these at the end of recovery, and
I got confused when you wrote that init forks just disappear. However
you were referring to the state of a cluster before recovery begins,
and I was thinking about the state where the cluster has run recovery
and has reached consistency.

If we should do something about such cases, then this brings us back
to do (INIT | CLEANUP) at the end of recovery anyway?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-05-27 02:19:39 Re: initdb recommendations
Previous Message Michael Paquier 2019-05-27 01:54:18 Re: Inconsistent error message wording for REINDEX CONCURRENTLY