Hello, At Fri, 18 Nov 2016 10:16:22 -0800, Andres Freund <and...@anarazel.de> wrote in <20161118181622.hklschaizwaxo...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
