On 2/19/25 19:45, Michael Paquier wrote:
> On Wed, Feb 19, 2025 at 05:35:18PM +0000, David Steele wrote:
>> I like this idea but I would prefer to get the patch committed as-is first.
>> The reason is that I'm hoping to see this batch-patched (since it is a bug)
>> and that is less likely if the message wording is change.
>
> (Had this thread flagged as a TODO for some time, sorry for not
> chiming in earlier.)
No worries. Thank you for having a look.
>> Your idea would be perfect going forward, though.
>
> We have a few logs that already track this information, but perhaps
> that's better to track this extra element in the FATAL if you have
> log_min_messages at fatal where LOG would not show up? Feel free to
> propose a separate patch if you think that this can be improved.
Benoit -- this was your idea. Did you want to submit a patch yourself?
> At a27048cbcb58, the check is done based on the copy of the checkpoint
> record, and the log is generated based on the checkpoint data in the
> control file. 4a92a1c3d1c3 has begun retrieving the replay TLI from
> the backup label. v13 and v14 have this issue, but I'm not really
> tempted to poke at the beast more than necessary as this code had a
> lot of changes in the last couple of years, with few to no complaints
> as far as I am aware.
Fair enough -- this is subtle enough that I doubt almost anyone is going
to notice and the general content of the error message is not really
changed by the incorrect values.
> Applied down to v15 where we have xlogrecovery.c, then. Thanks for
> the report!
Thank you for the commit!
Regards,
-David
