Question about InvalidatePossiblyObsoleteSlot()

From: "suyu(dot)cmj" <mengjuan(dot)cmj(at)alibaba-inc(dot)com>
To: "bertranddrouvot(dot)pg" <bertranddrouvot(dot)pg(at)gmail(dot)com>, "michael" <michael(at)paquier(dot)xyz>, "bharath(dot)rupireddyforpostgres" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "amit(dot)kapila16" <amit(dot)kapila16(at)gmail(dot)com>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Question about InvalidatePossiblyObsoleteSlot()
Date: 2025-09-23 14:38:14
Message-ID: f492465f-657e-49af-8317-987460cb68b0.mengjuan.cmj@alibaba-inc.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, all,
I have a question about a behavioral difference in InvalidatePossiblyObsoleteSlot() between PG15 (and earlier) and PG16 (and later):
In PG15 and earlier: while attempting to acquire a slot, if the slot's restart_lsn advanced to be greater than oldestLSN during the process, the slot would not be marked invalid.
In PG16 and later: the invalidation decision is made solely based on the initial_restart_lsn captured at the start of the check, even if the slot's restart_lsn advances above oldestLSN during the process, the slot may still be marked invalid.
I wonder why not decide whether to mark the slot as invalid based on the slot's current restart_lsn? If a slot's restart_lsn has already advanced sufficiently during the invalidation process, indicating it's actively being used, shouldn't we refrain from invalidating it? What is the rationale behind this design change?
Looking forward to your insights.
Best Regards,
suyu.cmj

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-23 14:39:02 Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master
Previous Message Andres Freund 2025-09-23 14:36:47 Re: AIX support