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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
