On 2025-Nov-06, Bertrand Drouvot wrote:
> I see, I would have introduced XLogRecPtrIsInvalid() on the back branches only
> if there is a need to (a bugfix that would make use of it). But yeah, I agree
> that would add extra "unnecessary" work, so done as you suggested in the
> attached. I checked that 0001 apply on the [14-18]_STABLE branches successfully.
Okay, thanks, I have applied that one to all stable branches, except I
didn't add the judgemental comment about XLogRecPtrIsInvalid().
I also pushed 0002+0004+0005 together as one commit, so now we have
XLogRecPtrIsValid() everywhere.
I did a couple of minor transformations, where the new code would end
doing "!XLogRecPtrIsValid(x) ? A : B" it seems clearer to remove the
negation and invert the other two arguments in the ternary. We also had
this assertion,
- Assert(XLogRecPtrIsInvalid(state->istartpoint) == (state->istarttli == 0));
which was being transformed to have a negation. I chose to negate the
other side of the equality instead, that is,
+ Assert(XLogRecPtrIsValid(state->istartpoint) == (state->istarttli != 0));
which also seems clearer.
Now only 0003 remains ... I would change the complaining version to 21
there, because why not?
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)
