Re: Inconsistent LSN format in pg_waldump output
От | Japin Li |
---|---|
Тема | Re: Inconsistent LSN format in pg_waldump output |
Дата | |
Msg-id | ME0P300MB04453A39931F95805C4205A8B64FA@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM обсуждение исходный текст |
Ответ на | Re: Inconsistent LSN format in pg_waldump output (Álvaro Herrera <alvherre@kurilemu.de>) |
Ответы |
Re: Inconsistent LSN format in pg_waldump output
|
Список | pgsql-hackers |
On Mon, 07 Jul 2025 at 14:18, Álvaro Herrera <alvherre@kurilemu.de> wrote: > On 2025-Jul-05, Masahiko Sawada wrote: > >> On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera <alvherre@kurilemu.de> wrote: >> > >> > On 2025-Jul-04, Japin Li wrote: >> > >> > > I've opted to directly use %X/%08X for LSN formatting in this patch, with an >> > > accompanying comment near LSN_FORMAT_ARGS. >> > >> > Thank you! I support this approach and intend to work on getting this >> > patch committed soon after some more review, unless there are further >> > objections. >> >> +1. I think we need to update LSN values in the documentation too. > > You're right, we had a few of those. I grepped for them and adjusted > what I found. I could have missed some, because there's a bunch of > other values that also look like slash-separated hexadecimal numbers. > The only case where I did something other than adding a leading zero was > the example output for gist_page_opaque_info() because I wasn't sure > that the 'nsn' column was also going to be printed as an LSN :-) so I > just ran the example query using one index from the regression database. > > And pushed. Thanks! Thank you for pushing this patch. I noticed some other areas in the documentation that could also use an update. diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml index 49a7c180a80..0994e089311 100644 --- a/doc/src/sgml/datatype.sgml +++ b/doc/src/sgml/datatype.sgml @@ -5121,7 +5121,7 @@ WHERE ... <literal>+(pg_lsn,numeric)</literal> and <literal>-(pg_lsn,numeric)</literal> operators, respectively. Note that the calculated LSN should be in the range of <type>pg_lsn</type> type, - i.e., between <literal>0/0</literal> and + i.e., between <literal>0/00000000</literal> and <literal>FFFFFFFF/FFFFFFFF</literal>. </para> </sect1> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 810b2b50f0d..c28aa71f570 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -28521,7 +28521,7 @@ acl | {postgres=arwdDxtm/postgres,foo=r/postgres} Returns information about the progress of the WAL summarizer. If the WAL summarizer has never run since the instance was started, then <literal>summarized_tli</literal> and <literal>summarized_lsn</literal> - will be <literal>0</literal> and <literal>0/0</literal> respectively; + will be <literal>0</literal> and <literal>0/00000000</literal> respectively; otherwise, they will be the TLI and ending LSN of the last WAL summary file written to disk. If the WAL summarizer is currently running, <literal>pending_lsn</literal> will be the ending LSN of the last I suggest we avoid changing the border style here. + lsn │ nsn │ rightlink │ flags +────────────┼────────────┼───────────┼──────── + 0/0B5FE088 │ 0/00000000 │ 1 │ {leaf} -- Regards, Japin Li
В списке pgsql-hackers по дате отправления: