Re: WAL recycle retading based on active sync rep.

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: craig(dot)ringer(at)2ndquadrant(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL recycle retading based on active sync rep.
Date: 2016-11-21 03:12:07
Message-ID: 20161121.121207.255432372.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for the comment.

At Fri, 18 Nov 2016 17:06:55 +0800, Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com> wrote in <CAMsr+YGkmJ2aweanT4JF9_i_xS_bGTZkdKW-_=2A88yEGansPA(at)mail(dot)gmail(dot)com>
> > We had too-early WAL recycling during a test we had on a sync
> > replication set. This is not a bug and a bit extreme case but is
> > contrary to expectation on synchronous replication.
>
> Isn't this prevented by using a physical replication slot?
>
> You hint that you looked at slots but they didn't meet your needs in some
> way. I'm not sure I understood the last part.

Yes, repslot does the similar. The point was whether "Do we
expect that removal of necessary WAL doesn't occur on an active
sync replication?", with a strong doubt.

At Fri, 18 Nov 2016 10:16:22 -0800, Andres Freund <andres(at)anarazel(dot)de> wrote in <20161118181622(dot)hklschaizwaxocl7(at)alap3(dot)anarazel(dot)de>
> On 2016-11-18 14:12:42 +0900, Kyotaro HORIGUCHI wrote:
> > We had too-early WAL recycling during a test we had on a sync
> > replication set. This is not a bug and a bit extreme case but is
> > contrary to expectation on synchronous replication.
>
> I don't think you can expect anything else.

I think this is the answer for it.

regards,

--
堀口恭太郎

日本電信電話株式会社 NTTオープンソースソフトウェアセンタ
Phone: 03-5860-5115 / Fax: 03-5463-5490

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tsunakawa, Takayuki 2016-11-21 03:20:41 Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Previous Message Tsunakawa, Takayuki 2016-11-21 02:16:06 Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows