Horton
Menu

Question about InvalidatePossiblyObsoleteSlot()

suyu.cmj <mengjuan.cmj@alibaba-inc.com>

View thread
From: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>
To: "bertranddrouvot.pg" <bertranddrouvot.pg@gmail.com>, "michael" <michael@paquier.xyz>, "bharath.rupireddyforpostgres" <bharath.rupireddyforpostgres@gmail.com>, "amit.kapila16" <amit.kapila16@gmail.com>
Cc: "pgsql-hackers" <pgsql-hackers@postgresql.org>
Date: 2025-09-23T14:38:14Z
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix regression with slot invalidation checks

  2. Fix race leading to incorrect conflict cause in InvalidatePossiblyObsoleteSlot()