Tatsuo Ishii <ishii@xxxxxxxxxxxxxx> wrote: > I think your problem is not relevant to pgpool-II. Agreed. > 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. > Primary server sends the committed transaction's WAL record to > standby and wait for it is written to the standby's WAL file (and > synched to the disk if synchronous_commit = on). Then report to > the client "the transaction has been committed". That means if > you send query on the just committed row to the standby, it may > returns an old row because WAL record may replay yet. Right. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
