On Wed, Sep 18, 2013 at 11:45 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko <sawada.m...@gmail.com> > wrote: >> On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao <masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
