On Tuesday, June 19, 2012 09:55:30 PM Robert Haas wrote:
> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund <andres@2ndquadrant.com>
wrote:
> > From: Andres Freund <andres@anarazel.de>
> >
> > The previous coding could miss xlog writeouts at several places. E.g.
> > when wal was written out by the background writer or even after a commit
> > if synchronous_commit=off.
> > This could lead to delays in sending data to the standby of up to 7
> > seconds.
> >
> > To fix this move the responsibility of notification to the layer where
> > the neccessary information is actually present. We take some care not to
> > do the notification while we hold conteded locks like WALInsertLock or
> > WalWriteLock locks.
>
> I am not convinced that it's a good idea to wake up every walsender
> every time we do XLogInsert(). XLogInsert() is a super-hot code path,
> and adding more overhead there doesn't seem warranted. We need to
> replicate commit, commit prepared, etc. quickly, by why do we need to
> worry about a short delay in replicating heap_insert/update/delete,
> for example? They don't really matter until the commit arrives. 7
> seconds might be a bit long, but that could be fixed by decreasing the
> polling interval for walsender to, say, a second.
Its not woken up every XLogInsert call. Its only woken up if there was an
actual disk write + fsync in there. Thats exactly the point of the patch.
The wakeup rate is actually lower for synchronous_commit=on than before
because then it unconditionally did a wakeup for every commit (and similar)
and now only does that if something has been written + fsynced.
> Parenthetically, I find it difficult to extract inline patches. No
> matter whether I try to use it using Gmail + show original or the web
> site, something always seems to get garbled.
Will use git send-mail --attach next time... Btw, git am should be able to
extract the patches for you.
Andres
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services