| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| 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:49:11 |
| Message-ID: | 202107160249.fjlmpg6vu3j5@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 2021-Jul-16, Kyotaro Horiguchi wrote:
> 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.
OK, I thought as much and tried to catch it in the act but couldn't.
Your explanation makes sense.
> 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.
Oh, true.
> I confirmed that *the previous* version of the test works for Windows.
> (So there's no reason that the current version doesn't work.)
Great, thanks.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Siempre hay que alimentar a los dioses, aunque la tierra esté seca" (Orual)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pawel Kudzia | 2021-07-16 07:06:59 | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
| Previous Message | PG Bug reporting form | 2021-07-16 02:39:06 | BUG #17112: Sequence number is not restored when the stored procedure ends abnormally |