> 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.
I understand you're point, but I think there's still a use case. The
idea is that declaring the secondary dead is a rare event, and there's
some mechanism by which you're enabled to page your network staff, and
they hightail it into the office to fix the problem. It might not be
the way that you want to run your system, but I don't think it's
unreasonable for someone else to want it.
> 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.
I agree that asynchronous mode will be the right solution for a very
large subset of our users.
...Robert
