Re: WalSndWakeup() and synchronous_commit=off

Hi,

On Friday, June 08, 2012 01:42:22 AM Simon Riggs wrote:
> On 7 June 2012 21:08, Andres Freund <andres@2ndquadrant.com> wrote:
> >> Moved the wakeup to a logical place outside a critical section.
> > 
> > Hm. I don't really like the way you implemented that. While it reduces
> > the likelihood quite a bit it will still miss wakeups if an XLogInsert
> > pushes out the data because of missing space or if any place does an
> > XLogFlush(lsn). The knowledge is really only available in XLogWrite...
> 
> Right, but the placement inside the critical section was objected to.
And that objection was later somewhat eased by Tom. There currently still are 
several WalSndWakeup calls in critical sections and several other uses of 
latches in critial sections and several in signal handlers (which may be 
during a critical section). Thats why I added comments to SetLatch documenting 
that they need to be signal/concurrency safe. (Which they are atm)

> This way, any caller of XLogFlush() will be swept up at least once per
> wal_writer_delay, so missing a few calls doesn't mean we have spikes
> in replication delay.
Unfortunately it does. At least I measure it here ;) (obviously less than the 
prev. 7 seconds). Its not that surprising though: Especially during high or 
even more so during bursty wal activity a backend might decide to write out 
wal itself. In that case the background writer doesn't necessarily have 
anything to write out so it won't wake the walsender.
Under high load the number of wakeups is twice or thrice as high *before* my 
patch than afterwards (with synchronous_commit=on obviously). As you most 
definitely know (group commit work et al) in a concurrent situation many of 
the wakeups from the current location (RecordTransactionCommit) are useless 
because the xlog was already flushed by another backend/background writer 
before we get to do it.

> Doing it more frequently was also an objection from Fujii, to which we
> must listen.
I had hoped that I argued successfully against that, but obviously not ;)

Greetings,

Andres
-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services