Re: Patch for fail-back without fresh backup

On Wed, Sep 18, 2013 at 1:05 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Wed, Sep 18, 2013 at 11:45 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>> On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> I set up synchronous replication with synchronous_transfer = all, and then I ran
>>>> pgbench -i and executed CHECKPOINT in the master. After that, when I executed
>>>> CHECKPOINT in the standby, it got stuck infinitely. I guess this was cased by
>>>> synchronous_transfer feature.
>>>
>>> Did you set synchronous_standby_names in the standby server?
>>
>> Yes.
>>
>>> If so, the master server waits for the standby server which is set to
>>> synchronous_standby_names.
>>> Please let me know detail of this case.
>>
>> Both master and standby have the same postgresql.conf settings as follows:
>>
>> max_wal_senders = 4
>> wal_level = hot_standby
>> wal_keep_segments = 32
>> synchronous_standby_names = '*'
>> synchronous_transfer = all
>>
>>>> How does synchronous_transfer work with cascade replication? If it's set to all
>>>> in the "sender-side" standby, it can resolve the data page inconsistency between
>>>> two standbys?
>>>>
>>>
>>> Currently patch supports the case which two servers are set up SYNC replication.
>>> IWO, failback safe standby is the same as SYNC replication standby.
>>> User can set synchronous_transfer in only master side.
>>
>> So, it's very strange that CHECKPOINT on the standby gets stuck infinitely.
>>

Sorry I sent mail by mistake.

yes I think so.

It waits for corresponding WAL replicated.
Behaviour of synchronous_transfer is similar to
synchronous_standby_names and synchronous replication little.
That is, if those parameter is set but the standby server doesn't
connect to the master server,
the master server waits for corresponding WAL replicated to standby
server infinitely.

I was not considering that user set synchronous_standby_names in the
standby server.
I will fix it considering this case.

Regards,

-------
Sawada Masahiko