Robert Haas wrote:
In fact, waiting for reply from standby server before acknowledging a commit
to the client is a bit pointless otherwise. It puts you in a strange
situation, where you're waiting for the commits in normal operation, but if
there's a network glitch or the standby goes down, you're willing to go
ahead without it. You get a high guarantee that your data is up-to-date in
the standby, except when it isn't. Which isn't much of a guarantee.
It protects you against a catastrophic loss of the primary, which is a
non-trivial consideration. At the risk of being ghoulish, imagine
that you are a large financial company headquartered in the world
trade center.
So you'd want all commits to wait until the transaction is safely
replicated in the standby. But if there's a network glitch, or the
standby is restarted, you're happy to reply to the client that it's
committed if it's only safely committed in the primary. Essentially, you
wait for the reply as long the standby responds within X seconds, but if
it takes more then Y seconds, you don't wait. I know that people do
that, but it seems counterintuitive to me. In that case, when the
primary acks the transaction as committed, you only know that it's
safely committed in the primary; it doesn't give any hard guarantee
about the state in the standby.
But when you consider the possibility to use the standby for queries,
the synchronous mode makes sense too.
I'm not opposed to providing all the options, but the synchronous mode
where we can guarantee that if you query the standby, you will see the
effects of all transactions committed in the primary, makes the
synchronous mode much more interesting. If you don't need that property,
you're most likely more happy with asynchronous mode anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
