On Wed, Oct 29, 2025 at 08:55:56AM +0000, Bertrand Drouvot wrote:
> 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.
This comment related to inactive_since that you have moved to its new
location has been added by ac0e33136abc, for v18~. Agreed that it is
important to keep that documented. The new location of this comment
feels OK.
> 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.
--
Michael
