Re: New wal format distorts pg_xlogdump --stats

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New wal format distorts pg_xlogdump --stats
Date: 2014-12-04 23:58:33
Message-ID: CAB7nPqT+LKrCpaKm=xCt91hmwqb3YEQpFcozJFm=DV4w8=r4Ag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 5, 2014 at 8:09 AM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:

> On 2014-12-04 16:26:02 +0200, Heikki Linnakangas wrote:
> > 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.
>
> I think both would be justifyable, so I don't really care for now. One
> slight reason for wrapping it in xlogreader.h is that we might add
> compression of some form or another soon and it'd possibly be better to
> have it in xlogreader.h so pg_xlogdump doesn't have to be changed. But
> that's really rather minor.
>

If we go this road and want to be complete, you may as well add access
macros for the image offset, the block image and for the block data stuff.
That would be handy and consistent with the rest, now both approaches are
fine as long as DecodedBkpBlock is in xlogreader.h.
Regards,
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-12-05 00:28:54 pg_basebackup -x/X doesn't play well with archive_mode & wal_keep_segments
Previous Message Jim Nasby 2014-12-04 23:50:51 Re: duplicated partial-column assigns allowed by checkInsertTargets