Re: [HACKERS] WAL logging problem in 9.4.3?
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: [HACKERS] WAL logging problem in 9.4.3? |
Дата | |
Msg-id | 20170411.095606.245908357.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] WAL logging problem in 9.4.3? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] WAL logging problem in 9.4.3?
|
Список | pgsql-hackers |
Hello, thank you for looking this. At Fri, 07 Apr 2017 20:38:35 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in <27309.1491611915@sss.pgh.pa.us> > Alvaro Herrera <alvherre@2ndquadrant.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. regards, -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: