Re: [HACKERS] Unlogged tables cleanup - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Unlogged tables cleanup
Date
Msg-id 20190523064248.GF5870@paquier.xyz
Whole thread Raw
In response to Re: [HACKERS] Unlogged tables cleanup  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Unlogged tables cleanup  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, May 21, 2019 at 08:39:18AM -0400, Robert Haas wrote:
> Yes.  I thought I had described it.  You create an unlogged table,
> with an index of a type that does not smgrimmedsync(), your
> transaction commits, and then the system crashes, losing the _init
> fork for the index.

The init forks won't magically go away, except in one case for empty
routines not going through shared buffers.

The empty routines writing pages which do not go through shared
buffers still log them, so those pages could go away when the host
crashes, and a checkpoint completed before calling smgrimmedsync() and
after the page has been logged.  Please note the logic in
spgbuildempty() as an example.

Then, empty routines going through shared buffers fill in one or more
buffers, mark it/them as empty, dirty it/them, log the page(s) and then
unlock the buffer(s).  If a crash happens after the transaction
commits, so we would still have the init page in WAL, and at the end
of recovery we would know about it.

Or is there something in log_newpage_buffer()/log_newpage() I am
missing but you foresee?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: PostgreSQL 12 Beta 1 press release draft
Next
From: Paul A Jungwirth
Date:
Subject: Re: docs about FKs referencing partitioned tables