Re: WAL logging problem in 9.4.3?

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: alvherre(at)2ndquadrant(dot)com, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, hlinnaka(at)iki(dot)fi, simon(at)2ndquadrant(dot)com, andres(at)anarazel(dot)de, masao(dot)fujii(at)gmail(dot)com, kleptog(at)svana(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL logging problem in 9.4.3?
Date: 2017-04-11 00:56:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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
pending-sync hash entry to Relation. This greately reduces the
frequency of hash-searching.

I'll post new patch in this way soon.


Kyotaro Horiguchi
NTT Open Source Software Center

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Gierth 2017-04-11 00:57:09 Ongoing issues with representation of empty arrays
Previous Message Stephen Frost 2017-04-11 00:55:01 Re: SUBSCRIPTIONS and pg_upgrade