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.
When I was doing some testing recently, the case that was sort of
confusing was the replay of AccessExcusiveLocks. The lock didn't show
up on the standby for many seconds after it had showed up on the
master. But that's more a feature than a bug when you really thinking
about it - postponing the lock on the slave for as long as possible
just reduces the user impact of having to take them there at all.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
