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