| 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 07:33:48 |
| Message-ID: | 20210715.163348.2298778826242193015.horikyota.ntt@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
At Thu, 15 Jul 2021 14:22:35 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
> At Wed, 14 Jul 2021 19:10:26 -0400, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote in
> > 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.
This is it. It is for the master branch but also applicable to 14 as
is. Not needed for earlier version.
I believe the test works for Windows but haven't checked.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Advance-old-segment-horizon-properly-after-slot-i.patch | text/x-patch | 6.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-07-15 07:42:16 | Re: BUG #17106: Renaming system types is possible and it potentially leads to a crash |
| Previous 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 |