From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | jeff(dot)janes(at)gmail(dot)com |
Cc: | mk(at)071(dot)ovh, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size |
Date: | 2021-07-15 05:22:35 |
Message-ID: | 20210715.142235.660428600377434237.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
At Wed, 14 Jul 2021 19:10:26 -0400, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote in
> On Tue, Jul 13, 2021 at 10:12 PM Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
> wrote:
> > Useless WAL files will be removd after a checkpoint runs.
> >
>
> They should be, but they are not. That is the bug. They just hang
> around, checkpoint after checkpoint. Some of them do get cleaned up, to
> make up for new ones created during that cycle. It treats
> max_slot_wal_keep the same way it treats wal_keep_size (but only if a
> "lost" slot is hanging around). If you drop the lost slot, only then does
> it remove all the accumulated WAL at the next checkpoint.
Thanks! I saw the issue here. Some investigation showd me a doubious
motion of XLogCtl->repliationSlotMinLSN. Slot invalidation is
forgetting to recalculate it and that misbehavior retreats the segment
horizon.
So the attached worked for me. I'll repost the polished version
including test.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
recalc_slotlsn_after_invalidation_PoC.patch | text/x-patch | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2021-07-15 07:04:46 | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
Previous Message | PG Bug reporting form | 2021-07-15 04:00:01 | BUG #17106: Renaming system types is possible and it potentially leads to a crash |