Re: Sync Rep: First Thoughts on Code

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