Tatsuo Ishii <ishii@postgresql.org> 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