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.


Andres Freund

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to