Re: xlogdump

Gregory Stark wrote:
> There's an xlogdump project on pgfoundry. However it suffers from perennial
> bitrot as it has to maintain its own table of xlog record types and code to
> decode each xlog record type.
> 
> ...
> 
> I think this module should be rewritten to depend more closely on the Postgres
> source files. What I'm doing now is making an SRF in the style of the
> pageinspect module which will read an arbitrary wal file and generate records
> directly.
> 
> This has a big disadvantage compared to the original approach, namely that you
> need a functioning Postgres instance of the same version to dissect wal
> records.
> 
> But it also has a big advantage, namely that it will always be in sync. It
> will just use the same RmgrTable to find the rm_name and call the rm_desc
> method to decode the record. The result might not be quite as or dense as the
> rm_desc function is meant for debugging messages. We could address that
> sometime with a new method if we wanted to.

Would it still be possible to compile it as a stand-alone program, using 
the backend source files? It would be a hack, we just went through some 
effort to clean up references to server private header files from ecpg 
and initdb, but it feels a lot nicer to use as a standalone program than 
requiring a running postgres instance.

How much infrastructure would you need to call rm_name and rm_desc from 
a standalone program? palloc and friends, I presume, What else?

> I'm thinking of actually dropping it directly into the pageinspect contrib
> module. It's not quite an exact fit but it doesn't seem to deserve it's own
> contrib module and it's likely to suffer the same bitrot problem if it lives
> in pgfoundry.

I'd vote for pgfoundry or a new contrib module. It shouldn't suffer from 
bitrot as easily as what's there now. That was the whole point of 
switching over to the new approach, right?

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com