Re: Inconsistent LSN format in pg_waldump output

From: Japin Li <japinli(at)hotmail(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Inconsistent LSN format in pg_waldump output
Date: 2025-07-03 10:19:17
Message-ID: ME0P300MB04454F397837414B471387E8B643A@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 03 Jul 2025 at 10:19, Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
> On 2025-Jul-03, Michael Paquier wrote:
>
>> Yep. If you do not want this new policy to be forgotten by new paths,
>> I'd suggested to standarize that with something like that, close to
>> the existing LSN_FORMAT_ARGS():
>> #define LSN_FORMAT "%X/%08X"
>
> Well, the reason we didn't use a macro in the format string is that
> translatability suffers quite a bit, and it's quite annoying. You can
> still use it in strings that aren't going to be translated -- for
> instance in all the xlog *_desc routines, in elog(), errmsg_internal(),
> errdetail_internal(). But for translatable messages such as errmsg(),
> errdetail, it's going to break. For example, one particular message in
> twophase.c was originally
>
> msgid "could not read two-phase state from WAL at %X/%X"
>
> after this patch, it becomes
>
> msgid "could not read two-phase state from WAL at "
>
> which is obviously broken. (You can test this by running "make
> update-po" and looking at the src/backend/po/*.po.new files. No idea
> hwo to do this under Meson, it doesn't seem documented.)
>

You're right; I overlooked it.

> Eyeballing the patch I think a majority of the messages are not
> translatable, so I'm still okay with adding and using the macro. But we
> need a revision to go back to literal %X/%08X in errmsg(), errdetail(),
> report_invalid_record(). I'd also add a comment next to the macro
> indicating that the macro MUST NOT be used for translatable strings, as
> it otherwise results in a bug that's only visible if you're running a
> version in a language other than English. I bet we're still going to
> get hackers use it badly, but not often.
>

Providing two LSN formats — %X%08X for translatable messages and
LSN_FORMAT for non-translatable ones — seems to offer no clear advantage.

I'd prefer to use %X/%08X directly and add the description to the
LSN_FORMAT_ARGS macro.

> The GNU gettext manual suggests you can print the value to a string
> variable and then use %s to include that in the translatable string, but
> I doubt that's an improvement over just using %X/%08X directly.
> Bottom of this page here:
> https://www.gnu.org/software/gettext/manual/html_node/No-string-concatenation.html
>

Yes, I don't consider that an improvement.

--
Regards,
Japin Li

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-07-03 10:51:31 Re: Conflict detection for update_deleted in logical replication
Previous Message Richard Guo 2025-07-03 10:06:47 Re: Pathify RHS unique-ification for semijoin planning