"Joshua D. Drake" <jd@commandprompt.com> writes:
> However, if the subscriber is down, the origin should NEVER wait. That
> is just silly behavior and makes synchronous replication pretty much
> useless. Machines go down, that is the nature of things. Yes, we should
> log and log loudly if the subscriber is down:
> ERROR: target xyz is non-communicative: switching to async replication.
> We then should store the wal logs up to wal_keep_segments.
> When the subscriber comes back up, it will then replicate in async mode
> until the two are back in sync and then switch (perhaps by hand) to sync
> mode. This of course assumes that we have a valid database on the
> subscriber and we have not overrun wal_keep_segments.
It sounds to me like you are describing the existing behavior of async
mode, with the possible exception of exactly what shows up in the
postmaster log.
Sync mode is about providing a guarantee that the data exists on more than
one server *before* we tell the client it's committed. If you don't need
that guarantee, you shouldn't be using sync mode. If you do need it,
it's not clear to me why you'd suddenly not need it the moment the going
actually gets tough.
regards, tom lane
