On Wed, Sep 18, 2013 at 11:45 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:
>> On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao <masao.fujii@gmail.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.
>
yes I think so.
I was not considering that user set synchronous_standby_names in the
standby server.
it will ocurr
I will fix it considering this case.
Regards,
-------
Sawada Masahiko