Re: New wal format distorts pg_xlogdump --stats - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: New wal format distorts pg_xlogdump --stats
Date
Msg-id 54806EFA.2030908@vmware.com
Whole thread Raw
In response to New wal format distorts pg_xlogdump --stats  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: New wal format distorts pg_xlogdump --stats  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 11/25/2014 05:36 AM, Andres Freund wrote:
> Hi,
>
> The new WAL format calculates FPI vs plain record data like:
>     rec_len = XLogRecGetDataLen(record) + SizeOfXLogRecord;
>     fpi_len = record->decoded_record->xl_tot_len - rec_len;
>
> Due to the amount of data now handled outside the main data portion ,
> that doesn't seem correct to me. As an example, a couple thousand
> inserts with full_page_writes=off now yields:
>
> Type                                           N      (%)          Record size      (%)             FPI size      (%)
      Combined size      (%) 
> ----                                           -      ---          -----------      ---             --------      ---
      -------------      --- 
> Heap/INSERT                                30167 ( 99.53)               814509 ( 99.50)               965856 ( 99.54)
            1780365 ( 99.52) 
>
> I think fpi_len now needs to only count the sum of the of the actual
> length of block images, and all the rest needs to be rec_len.

Yeah, that's broken.

I propose the attached. Or does anyone want to argue for adding an
XLogRecGetFPILen() accessor macro for the hole_length in xlogreader.h.
It's not something a redo routine would need, nor most XLOG-reading
applications, so I thought it's better to just have pg_xlogdump peek
into the DecodedBkpBlock struct directly.

- Heikki


Attachment

pgsql-hackers by date:

Previous
From: Alex Shulgin
Date:
Subject: Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps
Next
From: Craig Ringer
Date:
Subject: Re: libpq pipelining