Re: is sync rep stalled?

On Wed, Sep 29, 2010 at 11:47 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> So we've got two patches that implement synchronous replication, and
> no agreement on which one, if either, should be committed.  We have no
> agreement on how synchronous replication should be configured, and at
> most a tenuous agreement that it should involve standby registration.
>
> This is bad.
>
> This feature is important, and we need to get it done.  How do we get
> the ball rolling again?

ISTM that it still takes long to make consensus on standby registration.
So, how about putting the per-standby parameters in recovery.conf, and
focusing on the basic features in synchronous replication at first?
During that time, we can deepen discussion on standby registration, and
then we can implement that.

The basic features that I mean is for most basic use case, that is, one
master and one synchronous standby case. In detail,

> * Support multiple standbys with various synchronization levels.

Not required for that case.

> * What happens if a synchronous standby isn't connected at the moment? Return immediately vs. wait forever.

The wait-forever option is not required for that case. Let's implement
the return-immediately at first.

> * Per-transaction control. Some transactions are important, others are not.

Not required for that case.

> * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers can be seen as important special cases of this.

Not required for that case.

> * async, recv, fsync and replay levels of synchronization.

At least one of three synchronous levels should be included in the first
commit. I think that either recv or fsync is suitable for first try
because those don't require wake-up signaling from startup process to
walreceiver and are relatively easy to implement.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center