Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: movead(dot)li(at)highgo(dot)ca
Cc: michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org, ahsan(dot)hadi(at)highgo(dot)ca
Subject: Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
Date: 2020-10-14 01:29:44
Message-ID: 20201014.102944.102635524623180309.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 12 Oct 2020 09:46:37 +0800, "movead(dot)li(at)highgo(dot)ca" <movead(dot)li(at)highgo(dot)ca> wrote in
>
> Thanks for reply.
>
> >If you wish to add more information about a XLOG_SWITCH record, I
> >don't think that changing the signature of XLogDumpRecordLen() is
> >adapted because the record length of this record is defined as
> >Horiguchi-san mentioned upthread, and the meaning of junk_len is
> >confusing here. It seems to me that any extra information should be
> >added to xlog_desc() where there should be an extra code path for
> >(info == XLOG_SWITCH). XLogReaderState should have all the
> >information you are lookng for.
> We have two places to use the 'junk_len', one is when we show the
> detail record information, another is when we statistics the percent
> of all kind of wal record kinds(by --stat=record). The second place
> will not run the xlog_desc(), so it's not a good chance to do the thing.
>
> I am still can not understand why it can't adapted to change the
> signature of XLogDumpRecordLen(), maybe we can add a new function
> to caculate the 'junk_len' and rename the 'junk_len' as 'skiped_size' or
> 'switched_size'?

The reason is the function XLogDumpRecordLen is a common function
among all kind of LOG records, not belongs only to XLOG_SWICH. And the
junk_len is not useful for other than XLOG_SWITCH. Descriptions
specifc to XLOG_SWITCH is provided by xlog_desc().

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-10-14 01:48:18 Re: Two fsync related performance issues?
Previous Message Kyotaro Horiguchi 2020-10-14 01:18:38 Re: libpq debug log