Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments |
Дата | |
Msg-id | 20120427.154459.79590154.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: [BUG] Checkpointer on hot standby runs without
looking checkpoint_segments
|
Список | pgsql-hackers |
Hello, At Wed, 25 Apr 2012 02:31:24 +0900, Fujii Masao <masao.fujii@gmail.com> wrote in <CAHGQGwE1OvB=HLcahLeL5oP66sxsfsGMgwU3MqAAwZ_Vr=xh1w@mail.gmail.com> > > If we are allowed to be tolerant of the temporary lack of > > coherence in shared memory there, the spinlock could be removed. > > But the possibility to read garbage by using XLogCtl itself to > > access standbyMode does not seem to be tolerable. What do you > > think about that? > > I'm not sure if we really need to worry about that for such shared variable > that doesn't change since it's been initialized at the start of recovery. > Anyway, if we really need to worry about that, we need to protect the > shared variable RecoveryTargetTLI and archiveCleanupCommand with > the spinlock because they are in the same situation as standbyMode. From I said that the former (spinlock) could be dropped, but the latter (read as volatile) should be needed. From the view of maintenancibility (suspicious-proof expression?), it may be preferable that the manner to read shared memory be uniform whole source code if no particular reasons. Concerning this point, I think I will do 'volatization' and do not spinlock and put comment instead. regards, -- Kyotaro Horiguchi NTT Open Source Software Center == My e-mail address has been changed since Apr. 1, 2012.
В списке pgsql-hackers по дате отправления: