Re: [HACKERS] Restricting maximum keep segments by repslots
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Restricting maximum keep segments by repslots |
Дата | |
Msg-id | CAB7nPqRqhe1PgfoCEayj=bYuroEX4dP7CjWqhO_SwjTPErq6+A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Restricting maximum keep segments by repslots (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] Restricting maximum keep segments by repslots
|
Список | pgsql-hackers |
On Tue, Feb 28, 2017 at 1:16 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > It is doable without a plugin and currently we are planning to do > in the way (Maybe such plugin would be unacceptable..). Killing > walsender (which one?), removing the slot and if failed.. The PID and restart_lsn associated to each slot offer enough information for monitoring. > This is the 'steps rather complex' and fragile. The handling of slot drop is not complex. The insurance that WAL segments get recycled on time and avoid a full bloat is though. >> That's as well more flexible than having a parameter >> that basically is just a synonym of max_wal_size. > > I thought the same thing first, max_wal_size_hard, that limits > the wal size including extra (other than them for the two > checkpoig cycles) segments. It would make more sense to just switch max_wal_size from a soft to a hard limit. The current behavior is not cool with activity spikes. -- Michael
В списке pgsql-hackers по дате отправления: