Re: is sync rep stalled?

On Wed, Sep 29, 2010 at 3:56 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> 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.

I'm not sure this really gets us anywhere. We already have two
patches; writing a third one won't fix anything. We need to decide
which patch can be the basis for future work. According to my
understanding, the most significant difference between the patches is
the way that ACKs get sent from standby to master. Whose idea is
better, yours or Simon's? And why? Are there other reasons to prefer
one patch to the other?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company