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 →
  1. Fix regression with slot invalidation checks

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