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
