Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > All I'm saying is that if we end up shipping without that > parameter (implying allow_standalone_primary=on), we need to call > the feature something else. The GUCs and code can probably stay as > it is, but we shouldn't use the term "synchronous replication" in > the documentation, and release notes and such. I think including "synchronous" is OK as long as it's properly qualified. Off-hand thoughts in no particular order: semi-synchronous conditionally synchronous synchronous with automatic failover to standalone Perhaps the qualifications can be relaxed in some places but not others? The documentation should certainly emphasize that there is no guarantee that a successful commit means that the data is on at least two separate servers, if no such guarantee exists. If we expect that losing all replicas is such a terribly thin long shot that we don't need to worry about this difference, it is such a long shot that we don't need to worry about "wait forever" behavior, either; and we should just implement *that* so that no qualification is needed. I think that is an odd assumption, though; and I think a HA failover to weaker persistence guarantees in exchange for increased up-time would be popular. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
