On Mon, May 14, 2012 at 6:32 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On Friday, May 11, 2012 08:45:23 PM Tom Lane wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>> > Its the only place though which knows whether its actually sensible to
>> > wakeup the walsender. We could make it return whether it wrote anything
>> > and do the wakeup at the callers. I count 4 different callsites which
>> > would be an annoying duplication but I don't really see anything better
>> > right now.
>>
>> Another point here is that XLogWrite is not only normally called with
>> the lock held, but inside a critical section. I see no reason to take
>> the risk of doing signal sending inside critical sections.
>
>> BTW, a depressingly large fraction of the existing calls to WalSndWakeup
>> are also inside critical sections, generally for no good reason that I
>> can see. For example, in EndPrepare(), why was the call placed where
>> it is and not down beside SyncRepWaitForLSN?
> Hm. While I see no real problem moving it out of the lock I don't really see a
> way to cleanly outside critical sections everywhere. The impact of doing so
> seems to be rather big to me. The only externally visible place where it
> actually is known whether we write out data and thus do the wakeup is
> XLogInsert, XLogFlush and XLogBackgroundFlush. The first two of those are
> routinely called inside a critical section.
So what about moving the existing calls of WalSndWakeup() out of a critical
section and adding new call of WalSndWakeup() into XLogBackgroundFlush()?
Then all WalSndWakeup()s are called outside a critical section and after
releasing WALWriteLock. I attached the patch.
Regards,
--
Fujii Masao
