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

From Masahiko Sawada
Subject Re: Question about InvalidatePossiblyObsoleteSlot()
Date
Msg-id CAD21AoAPMf38G44KL7eAM_igdmYHahawJyjf_Pc_LhaLQHem8g@mail.gmail.com
Whole thread Raw
In response to Re: Question about InvalidatePossiblyObsoleteSlot()  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Question about InvalidatePossiblyObsoleteSlot()
Re: Question about InvalidatePossiblyObsoleteSlot()
List pgsql-hackers
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

>
> > 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.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: C11: should we use char32_t for unicode code points?
Next
From: Philip Alger
Date:
Subject: Re: [PATCH] Add pg_get_trigger_ddl() to retrieve the CREATE TRIGGER statement