Re: New wal format distorts pg_xlogdump --stats
От | Andres Freund |
---|---|
Тема | Re: New wal format distorts pg_xlogdump --stats |
Дата | |
Msg-id | 20141205003147.GF21964@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: New wal format distorts pg_xlogdump --stats (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: New wal format distorts pg_xlogdump --stats
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: