Re: Question about InvalidatePossiblyObsoleteSlot()
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>, michael <michael@paquier.xyz>, "bharath.rupireddyforpostgres" <bharath.rupireddyforpostgres@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-29T08:55:56Z
Lists: pgsql-hackers
Attachments
Hi, On Tue, Oct 28, 2025 at 11:53:26AM -0700, Masahiko Sawada wrote: > On Tue, Oct 28, 2025 at 1:58 AM Bertrand Drouvot > <bertranddrouvot.pg@gmail.com> wrote: > > > > Hi, > > > > On Mon, Oct 27, 2025 at 10:22:32AM -0700, Masahiko Sawada wrote: > > > On Thu, Oct 23, 2025 at 3:07 AM Bertrand Drouvot > > > > > seems no longer match what this > > > block of codes do. > > > > Agree. > > > > > It needs to be updated or moved to a more > > > appropriate place. > > > > What about moving it after? > > > > " > > * If the slot can be acquired, do so and mark it invalidated > > * immediately. Otherwise we'll signal the owning process, below, and > > * retry." > > > > That looks like a good place to me. > > +1 Done that way in v3 attached. Please note that v3 does not take into account the XLogRecPtrIsInvalid() remark as this will be part of a global effort and it's not directly linked to what we want to achieve here. > > > > > but I think > > > we might want to do something to deal with the inconsistency that we > > > originally wanted to address. > > > > I see, you mean that the tests are stable now (thanks to 105b2cb3361) but > > that we should still do something for "production" cases? (i.e not making use > > of injection points). > > Yes. While it seems we might want to review the past discussion, if > we've concluded such behavior is problematic behavior and could > confuse users, we can do something like improving the > invalidation/termination reports. Or we can do nothing if the current > reporting is fine. That's the test instability that triggered 818fefd8fd4 and not any report from the field. I think that pre-818fefd8fd4 behavior has been there for a while and that hitting the inconsistency is a pathological case. I'd vote for do nothing unless we get complaints from the field. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix regression with slot invalidation checks
- e3714dc059db 16.11 landed
- f3fb6bc9feec 17.7 landed
- bf3dba508ee1 18.1 landed
- d43209468906 19 (unreleased) landed
-
Fix race leading to incorrect conflict cause in InvalidatePossiblyObsoleteSlot()
- 818fefd8fd44 17.0 cited