Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: movead(dot)li(at)highgo(dot)ca, 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 06:52:43
Message-ID: 20201014065243.GA12403@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 14, 2020 at 10:29:44AM +0900, Kyotaro Horiguchi wrote:
> 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().

Yeah. In its current shape, it means that only pg_waldump would be
able to know this information. If you make this information part of
xlogdesc.c, any consumer of the WAL record descriptions would be able
to show this information, so it would provide a consistent output for
any kind of tools.

On top of that, it seems to me that the calculation used in the patch
is wrong in two aspects at quick glance:
1) startSegNo and endSegNo point always to two different segments with
a XLOG_SWITCH record, so you should check that ReadRecPtr is not at a
segment border instead before extracting SizeOfXLogLongPHD, no?
2) This stuff should also check after the case of a WAL *page* border
where you'd need to adjust based on SizeOfXLogShortPHD instead.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Luc Vlaming 2020-10-14 07:13:42 Re: Use list_delete_xxxcell O(1) instead of list_delete_ptr O(N) in some places
Previous Message denis.patron 2020-10-14 06:47:34 Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted