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.
