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 08:38:12 |
Message-ID: | 20170411.173812.133964522.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sorry, what I have just sent was broken.
At Tue, 11 Apr 2017 17:33:41 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20170411(dot)173341(dot)257028732(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> 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.
It contained tariling space and missing test script. This is the
correct patch.
> - 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.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
fix-wal-level-minimal-michael-horiguchi-2.patch | text/x-patch | 44.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Borodin | 2017-04-11 08:47:51 | Re: Merge join for GiST |
Previous Message | Kyotaro HORIGUCHI | 2017-04-11 08:33:41 | Re: WAL logging problem in 9.4.3? |