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