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-27T10:33:02Z
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
Attachments
- 0001-Overhaul-walsender-wakeup-handling.patch (text/x-patch) patch 0001
- 0002-Change-WalSndWakeupProcessRequests-and-WalSndWakeupR.patch (text/x-patch) patch 0002
On Tuesday, June 26, 2012 04:06:08 PM Andres Freund wrote: > On Tuesday, June 26, 2012 04:01:26 PM Robert Haas wrote: > > On Fri, Jun 22, 2012 at 12:35 PM, Andres Freund <andres@2ndquadrant.com> > > wrote: > > >> Can you elaborate on that a bit? What scenarios did you play around > > >> with, and what does "win" mean in this context? > > > > > > I had two machines connected locally and setup HS and my prototype > > > between them (not at once obviously). > > > The patch reduced all the average latency between both nodes (measured > > > by 'ticker' rows arriving in a table on the standby), the jitter in > > > latency and the amount of load I had to put on the master before the > > > standby couldn't keep up anymore. > > > > > > I played with different loads: > > > * multple concurrent ~50MB COPY's > > > * multple concurrent ~50MB COPY's, pgbench > > > * pgbench > > > > > > All three had a ticker running concurrently with synchronous_commit=off > > > (because it shouldn't cause any difference in the replication pattern > > > itself). > > > > > > The difference in averagelag and cutoff were smallest with just pgbench > > > running alone and biggest with COPY running alone. Highjitter was most > > > visible with just pgbench running alone but thats likely just because > > > the average lag was smaller. > > > > OK, that sounds pretty promising. I'd like to run a few performance > > tests on this just to convince myself that it doesn't lead to a > > significant regression in other scenarios. Assuming that doesn't turn > > up anything major, I'll go ahead and commit this. > > Independent testing would be great, its definitely possible that I oversaw > something although I obviously don't think so ;). > > > Can you provide a rebased version? It seems that one of the hunks in > > xlog.c no longer applies. > > Will do so. Not sure if I can finish it today though, I am in the midst of > redoing the ilist and xlogreader patches. I guess tomorrow will suffice > otherwise... Ok, attached are two patches: The first is the rebased version of the original patch with WalSndWakeupProcess renamed to WalSndWakeupProcessRequests (seems clearer). The second changes WalSndWakeupRequest and WalSndWakeupProcessRequests into macros as you requested before. I am not sure if its a good idea or not. Anything else? Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services