Re: [PATCH 01/16] Overhaul walsender wakeup handling
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: pgsql-hackers@postgresql.org
Cc: Robert Haas <robertmhaas@gmail.com>
Date: 2012-06-19T20:07:36Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't waste the last segment of each 4GB logical log file.
- dfda6ebaec67 9.3.0 cited
-
Stamp HEAD as 9.3devel.
- bed88fceac04 9.3.0 cited
-
Wake WALSender to reduce data loss at failover for async commit.
- 2c8a4e9be273 9.2.0 cited
-
Make the visibility map crash-safe.
- 503c7305a1e3 9.2.0 cited
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