Re: Error with index on unlogged table - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Error with index on unlogged table
Date
Msg-id CAB7nPqSD4yw=p39Ei4gjf=HN_8kD=npSOKa1fQT3q3O2cTYDHQ@mail.gmail.com
Whole thread Raw
In response to Re: Error with index on unlogged table  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Error with index on unlogged table  (Michael Paquier <michael.paquier@gmail.com>)
Re: Error with index on unlogged table  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Nov 20, 2015 at 7:03 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown <thom@linux.com> wrote:
>> This bug still exists.
>
> Hmm.  This probably should have been on the open items list.

I have added an open item for 9.5. That's not a cool bug to release
the next GA even if that's not limited to 9.5, it is easily
reproducible in older stable branches as well.

> I didn't
> pay too much attention this to this before because it seemed like
> Andres and Michael were all over it.

This completely fell off my radar. Sorry about that.

For back-branches, I tend to agree with what Horiguchi-san mentioned
upthread: we had better issue an unconditional fsync on the relation
when INIT_FORKNUM is used for it when replaying XLOG_FPI record. That
would rather localize the impact. An example of patch is attached that
applies on top of REL9_4_STABLE. That's rather ugly but it shows the
idea and fixes the issue.

For master and perhaps 9.5, I would think that a dedicated WAL record
type enforcing the fsync is the way to go. This special treatment
would go only for btree and spgist when they use INIT_FORKNUM and we
would not impact other relation types and code paths with this
behavior.

Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [DESIGN] ParallelAppend
Next
From: Noah Misch
Date:
Subject: Re: RLS open items are vague and unactionable