Re: Standalone synchronous master

Josh Berkus <josh@agliodbs.com>

From: Josh Berkus <josh@agliodbs.com>
To: Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@2ndquadrant.com>
Cc: "Joshua D. Drake" <jd@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kevin Grittner <kgrittn@ymail.com>, Bruce Momjian <bruce@momjian.us>, Heikki Linnakangas <hlinnakangas@vmware.com>, Simon Riggs <simon@2ndQuadrant.com>, Rajeev rastogi <rajeev.rastogi@huawei.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2014-01-08T23:15:21Z
Lists: pgsql-hackers
Stephen,


> I'm aware, my point was simply that we should state, up-front in
> 25.2.7.3 *and* where we document synchronous_standby_names, that it
> requires at least three servers to be involved to be a workable
> solution.

It's a workable solution with 2 servers.  That's a "low-availability,
high-integrity" solution; the user has chosen to double their risk of
not accepting writes against never losing a write.  That's a perfectly
valid configuration, and I believe that NTT runs several applications
this way.

In fact, that can already be looked at as a kind of "auto-degrade" mode:
if there aren't two nodes, then the database goes read-only.

Might I also point out that transactions are synchronous or not
individually?  The sensible configuration is for only the important
writes being synchronous -- in which case auto-degrade makes even less
sense.

I really think that demand for auto-degrade is coming from users who
don't know what sync rep is for in the first place.  The fact that other
vendors are offering auto-degrade as a feature instead of the ginormous
foot-gun it is adds to the confusion, but we can't help that.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com