Kevin,
I see your point, and totally agree. The documentation is pretty clear about this.
I indeed want the security brought by synchronous replication. Having a commit no to return as long as the replica is not up-and-streaming is what I expect and perfectly fits my needs. It is perfectly right in my use case for the master to wait for the replica as long as necessary. Asynchronous replication is definitely not what I want.
My concern here is that, although the slave is back, the pending commit is not performed on the master side. I'd expect all ongoing and blocking commits to be unblocked as soon as the slave pops in. Since the master and slave are synchronous after the slave is back, what's the point in holding a transaction forever in the master's backend ?
Regards,
Sekine