Re: WAL logging problem in 9.4.3?

At Tue, 11 Apr 2017 09:56:06 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20170411(dot)095606(dot)245908357(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> Hello, thank you for looking this.
>
> At Fri, 07 Apr 2017 20:38:35 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <27309(dot)1491611915(at)sss(dot)pgh(dot)pa(dot)us>
> > Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > > Interesting. I wonder if it's possible that a relcache invalidation
> > > would cause these values to get lost for some reason, because that would
> > > be dangerous.
> >
> > > I suppose the rationale is that this shouldn't happen because any
> > > operation that does things this way must hold an exclusive lock on the
> > > relation. But that doesn't guarantee that the relcache entry is
> > > completely stable,
> >
> > It ABSOLUTELY is not safe. Relcache flushes can happen regardless of
> > how strong a lock you hold.
> >
> > regards, tom lane
>
> Ugh. Yes, relcache invalidation happens anytime and it resets the
> added values. pg_stat_info deceived me that it can store
> transient values. But I came up with another thought.
>
> The reason I proposed it was I thought that hash_search for every
> buffer is not good. Instead, like pg_stat_info, we can link the

buffer => buffer modification

> pending-sync hash entry to Relation. This greately reduces the
> frequency of hash-searching.
>
> I'll post new patch in this way soon.

Here it is.

- Relation has new members no_pending_sync and pending_sync that
works as instant cache of an entry in pendingSync hash.

- Commit-time synchronizing is restored as Michael's patch.

- If relfilenode is replaced, pending_sync for the old node is
removed. Anyway this is ignored on abort and meaningless on
commit.

- TAP test is renamed to 012 since some new files have been added.

Accessing pending sync hash occured on every calling of
HeapNeedsWAL() (per insertion/update/freeze of a tuple) if any of
accessing relations has pending sync. Almost of them are
eliminated as the result.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center