Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: alvherre(at)alvh(dot)no-ip(dot)org
Cc: jeff(dot)janes(at)gmail(dot)com, 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-16 02:05:00
Message-ID: 20210716.110500.137369520113769822.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Thu, 15 Jul 2021 17:33:20 -0400, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote in
> On 2021-Jul-15, Alvaro Herrera wrote:
>
> > Actually, looking again, isn't this supposed to happen in KeepLogSeg()?
> > We have a block that caps to max_slot_wal_keep_size_mb there ... why did
> > that not work?
>
> I find that this smaller patch is sufficient to make the added test case
> work. However, I'm not sure I understand *why* ...

It's because another checkpoint is running at the time the manual
checkpoint just before is invoked. Two successive checkpoint hides
the defect. The checkpoint works as the rendezvous point for the
succeeding tests so I added another sync point instead of the manual
checkpoint. The test in the attached correctly fails if _logSegNo
were not updated by slot invalidation.

By the way, about the previous version, XLByteToSeg is needed since
KeepLogSeg doesn't advance _logSegNo, which is the wanted action
here. The test in the attached fails if only KeepLogSeg is called
again.

I confirmed that *the previous* version of the test works for Windows.
(So there's no reason that the current version doesn't work.)

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
v6-0001-Advance-old-segment-horizon-properly-after-slot-i.patch text/x-patch 8.0 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-07-16 02:39:06 BUG #17112: Sequence number is not restored when the stored procedure ends abnormally
Previous Message Alexander Korotkov 2021-07-15 22:59:45 Re: BUG #17066: Cache lookup failed when null (unknown) is passed as anycompatiblemultirange