Re: Maximum number of WAL files in the pg_xlog directory
| От | Guillaume Lelarge |
|---|---|
| Тема | Re: Maximum number of WAL files in the pg_xlog directory |
| Дата | |
| Msg-id | CAECtzeXB0=P4K6cbNKW-rJ4OQCW_LuxKBEBx3P1c6zK4EgJNCA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Maximum number of WAL files in the pg_xlog directory (Jeff Janes <jeff.janes@gmail.com>) |
| Список | pgsql-hackers |
2014-12-30 18:45 GMT+01:00 Jeff Janes <jeff.janes@gmail.com>:
OK, that seems much better. Thanks, Jeff.
--
On Tue, Dec 30, 2014 at 12:35 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote:Sorry for my very late answer. It's been a tough month.2014-11-27 0:00 GMT+01:00 Bruce Momjian <bruce@momjian.us>:On Mon, Nov 3, 2014 at 12:39:26PM -0800, Jeff Janes wrote:
> It looked to me that the formula, when descending from a previously stressed
> state, would be:
>
> greatest(1 + checkpoint_completion_target) * checkpoint_segments,
> wal_keep_segments) + 1 +
> 2 * checkpoint_segments + 1
I don't think we can assume checkpoint_completion_target is at all
reliable enough to base a maximum calculation on, assuming anything
above the maximum is cause of concern and something to inform the admins
about.
Assuming checkpoint_completion_target is 1 for maximum purposes, how
about:
max(2 * checkpoint_segments, wal_keep_segments) + 2 * checkpoint_segments + 2Seems something I could agree on. At least, it makes sense, and it works for my customers. Although I'm wondering why "+ 2", and not "+ 1". It seems Jeff and you agree on this, so I may have misunderstood something.From hazy memory, one +1 comes from the currently active WAL file, which exists but is not counted towards either wal_keep_segments nor towards recycled files. And the other +1 comes from the formula for how many recycled files to retain, which explicitly has a +1 in it.
OK, that seems much better. Thanks, Jeff.
--
В списке pgsql-hackers по дате отправления: