Re: hash index on unlogged tables doesn't behave as expected

FWIW..

At Thu, 06 Jul 2017 18:54:47 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20170706.185447.256482539.horiguchi.kyotaro@lab.ntt.co.jp>
> > > +       /*
> > > +        * Force the on-disk state of init forks to always be in sync with the
> > > +        * state in shared buffers.  See XLogReadBufferForRedoExtended.
> > > +        */
> > > +       XLogRecGetBlockTag(record, 0, NULL, &forknum, NULL);
> > > +       if (forknum == INIT_FORKNUM)
> > > +               FlushOneBuffer(metabuf);
> > > I find those forced syncs a bit surprising. The buffer is already
> > > marked as dirty, so even if there is a concurrent checkpoint they
> > > would be flushed.
> > >
> > 
> > What if there is no concurrent checkpoint activity and the server is
> > shutdown?  Remember this replay happens on standby and we will just
> > try to perform Restartpoint and there is no guarantee that it will
> > flush the buffers.  If the buffers are not flushed at shutdown, then
> > the Init fork will be empty on restart and the hash index will be
> > corrupt.
> 
> XLogReadBufferForRedoExtended() automatically force the flush for
> a XLOG record on init fork that having FPW imaeges. And
> _hash_init seems to have emitted such a XLOG record using
> log_newpage.
> 
> > > If recovery comes again here, then they would just
> > > be replayed. I am unclear why XLogReadBufferForRedoExtended is not
> > > enough to replay a FPW of that.
> > >
> > 
> > Where does FPW come into the picture for a replay of metapage or bitmappage?
> 
> Since required FPW seems to be emitted and the flush should be
> done automatically, the issuer side (_hash_init) may attach wrong

"may attach" -> "may have attached"

> FPW images if hash_xlog_init_meta_page requires additional
> flushes. But I don't see such a flaw there. I think Michael wants
> to say such a kind of thing.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center