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

From Bertrand Drouvot
Subject Re: Question about InvalidatePossiblyObsoleteSlot()
Date
Msg-id aQLnEne32N8m/i7O@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Question about InvalidatePossiblyObsoleteSlot()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Question about InvalidatePossiblyObsoleteSlot()
List pgsql-hackers
Hi,

On Thu, Oct 30, 2025 at 11:25:18AM +0900, Michael Paquier wrote:
> On Wed, Oct 29, 2025 at 08:55:56AM +0000, Bertrand Drouvot wrote:
> 
> > 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.
> 
> I am not sure that there is anything else to be done, but let's just
> revert the change in v16~ for now.  As far as I can see, the change is
> straight-forward in v16, slightly funky in v17 as "invalidation_cause"
> is a rename of "conflict", while your patch captures the refactoring
> of v18~ under DetermineSlotInvalidationCause().  I have run a few
> hundred loops of 035_standby_logical_decoding for v16 and v17, in
> case, without seeing problems.  Now the original race was also hard to
> see.

The tests are also stabilized on 17 thanks to 17a165d60f73 and on 16 thanks
to 86392e8827d8, so I think that we should be fine on those branches too.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [PING] fallocate() causes btrfs to never compress postgresql files
Next
From: David Rowley
Date:
Subject: Re: Have the planner convert COUNT(1) / COUNT(not_null_col) to COUNT(*)