Обсуждение: Re: Inconsistent LSN format in pg_waldump output

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.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

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!

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"No tengo por qué estar de acuerdo con lo que pienso"
                             (Carlos Caszeli)

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

On 2025-Jul-07, Japin Li wrote:

> Thank you for pushing this patch.  I noticed some other areas in the
> documentation that could also use an update.

Thanks!  Pushed these fixes.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.

I found an old patch in my local worktree closely related to this work;
here we take the additional step of changing the pattern used for .snap
file names in logical decoding to use %X/%08X as the other patterns we
changed for this.  This changes both the sscanf() part of it as well as
sprinft().

Any objections against this?

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/