Heikki Linnakangas wrote:
> 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?
Do you actually need palloc and friends, or just "something named
palloc"? We already have some stuff in src/port that deals with using
palloc calls in routines used in frontend programs...
//Magnus
