Re: WAL recycle retading based on active sync rep.

Hello,

At Fri, 18 Nov 2016 10:16:22 -0800, Andres Freund <andres@anarazel.de> wrote in
<20161118181622.hklschaizwaxocl7@alap3.anarazel.de>
> Hi,
> 
> 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.

My sentense was inaccurate. "is contrary to *naive* expectation
on synchronous replication." But I agree to you.

> > This is because sync replication doesn't wait non-commit WALs to
> > be replicated. This situation is artificially caused with the
> > first patch attached and the following steps.
> 
> You could get that situation even if we waited for syncrep. The
> SyncRepWaitForLSN happens after delayChkpt is unset.
> 
> Additionally a syncrep connection could break for a a short while, and
> you'd loose all guarantees anyway.

I know. Replication slots are for such cases.

> > - Is this situation required to be saved? This is caused by a
> >   large transaction, spans over two max_wal_size segments, or
> >   replication stall lasts for a chackepoint period.
> 
> I very strongly think not.
> 
> 
> > - Is the measure acceptable?  For the worst case, a master
> >   crashes from WAL space exhaustion. (But such large transaction
> >   won't/shouldn't exist?)
> 
> No, imo not.

Thanks for clarifying that.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center