On 2014-12-05 08:58:33 +0900, Michael Paquier wrote:
> On Fri, Dec 5, 2014 at 8:09 AM, Andres Freund <andres@2ndquadrant.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.
I don't see the point. Let's introduce that if (which I doubt a bit)
there's a user.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
