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. > 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. > - 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. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
