On Fri, Nov 20, 2015 at 7:03 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Nov 19, 2015 at 7:19 AM, Thom Brown <t...@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
20151120_xlog_fpi_replay.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
