Re: WAL recycle retading based on active sync rep.
От | Andres Freund |
---|---|
Тема | Re: WAL recycle retading based on active sync rep. |
Дата | |
Msg-id | 20161118181622.hklschaizwaxocl7@alap3.anarazel.de обсуждение исходный текст |
Ответ на | WAL recycle retading based on active sync rep. (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: WAL recycle retading based on active sync rep.
Re: WAL recycle retading based on active sync rep. |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: