From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(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-13 17:52:21 |
Message-ID: | 20190513175221.atddcrnn2qeot527@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-05-13 13:33:00 -0400, Alvaro Herrera wrote:
> On 2019-May-13, Andres Freund wrote:
>
> > On 2019-05-13 13:07:30 -0400, Alvaro Herrera wrote:
> > > On 2019-May-13, Andres Freund wrote:
>
> > > The first ResetUnloggedRelations call occurs before any WAL is replayed,
> > > so the data dir certainly still in inconsistent state. At that point,
> > > we need the init fork files to be present, because the init files are the
> > > indicators of what relations we need to delete the other forks for.
> >
> > Hm. I think this might be a self-made problem. For the main fork, we
> > don't need this - if the init fork was created before the last
> > checkpoint/restartpoint, it'll be on-disk. If it was created afterwards,
> > WAL replay will recreate both main an init fork. So the problem is just
> > that the VM fork might survive, because it'll not get nuked given the
> > current arrangement. Is that what you're thinking about?
I was wrong here - I thought we WAL logged the main fork creation even
for unlogged tables. I think it's foolish that we don't, but we don't.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-05-13 17:53:17 | Re: SQL-spec incompatibilities in similar_escape() and related stuff |
Previous Message | Justin Pryzby | 2019-05-13 17:48:00 | Re: pg12 release notes |