Обсуждение: Question about InvalidatePossiblyObsoleteSlot()

Поиск
Список
Период
Сортировка

Question about InvalidatePossiblyObsoleteSlot()

От
"suyu.cmj"
Дата:
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

Re: Question about InvalidatePossiblyObsoleteSlot()

От
Bertrand Drouvot
Дата:
Hi,

On Tue, Sep 23, 2025 at 10:38:14PM +0800, suyu.cmj wrote:
> 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
oldestLSNduring 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
thecheck, 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_lsnhas already advanced sufficiently during the invalidation process, indicating it's actively being used,
shouldn'twe refrain from invalidating it? What is the rationale behind this design change?
 
> Looking forward to your insights.

That comes from 818fefd8fd4. Does the wording in the commit message ([1]) and the
linked thread ([2]) answer your question?

[1]: postgr.es/c/818fefd8fd4
[2]: postgr.es/m/ZaTjW2Xh+TQUCOH0@ip-10-97-1-34.eu-west-3.compute.internal

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com