Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Markus Wanner <markus@bluegap.ch>
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-23T15:24:30Z
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 →
-
Efficient transaction-controlled synchronous replication.
- a8a8a3e09652 9.1.0 cited
On Wed, Mar 23, 2011 at 8:16 AM, Markus Wanner <markus@bluegap.ch> wrote: > 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? Well, just the one we were talking about: a COMMIT on one node doesn't guarantee that the transactions is visible on the other node, just that it will become visible there eventually, even if a crash happens. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company