Re: 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>
Cc: "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>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about InvalidatePossiblyObsoleteSlot()
Date: 2025-10-09 02:49:39
Message-ID: d14d50bf-5c05-4a72-88e1-58e103c2ec0c.mengjuan.cmj@alibaba-inc.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
Thank you for the reference to commit 818fefd8fd4 and the related discussion thread. I understand the intent of introducing initial_restart_lsn was to preserve a consistent invalidation cause throughout the invalidation loop.
However, I still have a few concerns about this design change:
1. I understand the intention to keep the invalidation cause consistent, but If a slot's restart_lsn advances significantly during the invalidation check—indicating it is actively in use—shouldn't we reconsider invalidating it?
2. What potential issues arise if we refrain from invalidating slots whose restart_lsn advances during the invalidation process? Intuitively, an actively used slot that has moved it's restart_lsn beyond the problematic point should not be marked invalid.
3. If the current approach is indeed correct, should we consider making PG15 and earlier consistent with this behavior? The behavioral difference across versions may lead to different operational outcomes in otherwise similar situations.
I would appreciate your insights on these points.
Best regards,
suyu.cmj

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-09 03:04:37 Re: plan shape work
Previous Message Peter Smith 2025-10-09 02:36:36 Re: duplicate logging in pg_createsubscriber