Re: "no-slave yet" early CREATE TABLE transaction gets blocked when synchronous replication

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

2015-03-25 15:31 GMT+01:00 Kevin Grittner <kgrittn(at)ymail(dot)com>:

> Sékine Coulibaly <scoulibaly(at)gmail(dot)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
>