Horton

Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.

Markus Wanner <markus@bluegap.ch>

View thread
From: Markus Wanner <markus@bluegap.ch>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Aidan Van Dyk <aidan@highrise.ca>, Simon Riggs <simon@2ndquadrant.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, MARK CALLAGHAN <mdcallag@gmail.com>, Alvaro Herrera <alvherre@commandprompt.com>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-03-23T12:16:39Z
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 →

  1. Efficient transaction-controlled synchronous replication.

On 03/23/2011 12:52 PM, Robert Haas wrote:
> Yes.  What this won't do is let you build a big load-balancing network
> (at least not without great caution about what you assume).

This sounds too strong to me.  Session-aware load balancing is pretty
common these days.  It's the default mode of PgBouncer, for example.
Not much caution required there, IMO.  Or what pitfalls did you have in
mind?

> What it
> will do is make it really, really hard to lose committed transactions.
> Both good things, but different.

..you can still get both at the same time.  At least as long as you are
happy with session-aware load balancing.  And who really needs finer
grained balancing?

(Note that no matter how fine-grained you balance, you are still bound
to a (single core of a) single node.  That changes with distributed
querying, and things really start to get interesting there... but we are
far from that, yet).

Regards

Markus