Re: Question about InvalidatePossiblyObsoleteSlot() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Question about InvalidatePossiblyObsoleteSlot()
Date
Msg-id aQKws-mnJ3mqQdtx@paquier.xyz
Whole thread Raw
In response to Re: Question about InvalidatePossiblyObsoleteSlot()  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Wed, Oct 29, 2025 at 11:05:12AM -0700, Masahiko Sawada wrote:
> On Wed, Oct 29, 2025 at 12:02 AM Michael Paquier <michael@paquier.xyz> wrote:
>> Anyway, coming back to the patch, the argument of relying on the
>> slot's restart_lsn and the two xmins to restore the pre-818fefd8fd4
>> sounds good to me in light of 105b2cb3361.
>
> BTW do you think restoring the pre-818fefd8fd4 behavior is going to be
> backpatched?

With 105b2cb3361 being introduced in v16, restoring the past behavior
on all the branches sounds good to me.  I prefer the long-term
solution that we have in 18 and newer branches, but we don't have
IS_INJECTION_POINT_ATTACHED() in the v16 and v17 branches, so there is
not much more to do.  It would be better to move quickly on this one
to make sure that we do not make v16 and v17 again unstable by the
next minor release.

With this timing in mind and an upcoming long weekend in Japan (11/3),
I am tempted to do something about that today as I'll be able to
monitor the buildfarm for a bit more time.

> I don't think we need to put the assertion there, but it would be good
> if we could mention somewhere as comments why it's safe to skip the
> slot invalidation when the slot's xmin or restart_lsn get advanced
> across two loops.

Okay, noted.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix bogus use of "long" in aset.c
Next
From: "Matheus Alcantara"
Date:
Subject: Re: postgres_fdw: Use COPY to speed up batch inserts