S=C3=A9kine Coulibaly <scoulibaly@gmail.com> wrote:
> synchronous replication. When a transaction is received by the
> master before the slave is up and running, the transaction seems
> blocked forever on the backend.
This is not a bug. The promise made for synchronous replication is
that when a commit returns an indication of success, the
transaction has been persisted on at least two clusters. If you
don't want that promise yet, don't turn on synchronous replication
yet. If you want that guarantee but you want the primary to be
able to continue to commit transactions when there is a failure of
a synchronous replica, then provide more than one synchronous
replica.
There was discussion of supporting a "don't actually provide that
guarantee, but kinda try when it's responding fast enough", but
that was rejected as being so close to asynchronous replication as
to not really add any value. All it would do is stall the
successful return of a commit request without actually giving you
any stronger guarantee than asynchronous replication. Effectively,
any product that behaves that way is just giving you a false sense
of security. If you don't need the guarantee of a second copy of
the transaction having been persisted to a second cluster, use
asynchronous replication.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
