From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Restricting maximum keep segments by repslots |
Date: | 2017-02-28 04:34:54 |
Message-ID: | CAB7nPqRqhe1PgfoCEayj=bYuroEX4dP7CjWqhO_SwjTPErq6+A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 28, 2017 at 1:16 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kuntal Ghosh | 2017-02-28 04:50:18 | Re: increasing the default WAL segment size |
Previous Message | 钱新林 | 2017-02-28 04:31:57 | help to identify the reason that extension's C function returns array get segmentation fault |