Re: is sync rep stalled?

On 29.09.2010 10:56, Fujii Masao wrote:
> On Wed, Sep 29, 2010 at 11:47 AM, Robert Haas<robertmhaas@gmail.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?

Agreed. Actually, given the lack of people jumping in and telling us 
what they'd like to do with the feature, maybe it's not that important 
after all.

> 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,

ISTM the problem is exactly that there is no consensus on what the basic 
use case is. I'm sure there's several things you can accomplish with 
synchronous replication, perhaps you could describe what the important 
use case for you is?

>> * Support multiple standbys with various synchronization levels.
>
> Not required for that case.

IMHO at least we'll still need to support asynchronous standbys in the 
same mix, that's an existing feature.

>> * 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.
>
> ..-
>
>> * 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.

What is the use case for that combination? For zero data loss, you 
*must* wait forever if a standby isn't connected. For keeping a hot 
standby server up-to-date so that you can freely query the standby 
instead of the master, you need replay level synchronization.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com