>> PostgreSQL's "synchronous" replication is actually not >> synchronous > > Well, that statement is a bit misleading. What is synchronous with > the COMMIT request is that data is persisted on at least two > targets before the COMMIT request returns an indication of success. > It guarantees that much (which some people complain about because > if there is only one synchronous replication target the commit > request hangs indefinitely if it, or communications to it, goes > down) and no more (because some people expect that it is not just > about durability, but also about visibility). There have been many > discussions about allowing configuration of broader or less strict > guarantees, but for now, you have just the one option. > >> (it's confusing but the naming was developer's decision). > > There was much discussion at the time, and this was the consensus > for an initial implementation. I know what PostgreSQL's synchronous replication does. But, as you saw, still many users expect "synchronous replication" will do "visibility synchronous". I'm a little bit tired of making this kind of explanation to users but that's not users fault, I think. Maybe "crash safe replication" or some such was more appropriate term, but of course this is just a hindsight. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
