From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: xlogdump |
Date: | 2007-11-02 11:09:09 |
Message-ID: | 472B0555.4020804@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-11-02 11:17:15 | Re: xlogdump |
Previous Message | Gregory Stark | 2007-11-02 10:54:45 | xlogdump |