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 |
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 |