Re: Consistently use the XLogRecPtrIsInvalid() macro
| От | Álvaro Herrera |
|---|---|
| Тема | Re: Consistently use the XLogRecPtrIsInvalid() macro |
| Дата | |
| Msg-id | 202511061936.ivzq6rvsny27@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: Consistently use the XLogRecPtrIsInvalid() macro (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Ответы |
Re: Consistently use the XLogRecPtrIsInvalid() macro
|
| Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: