After some fooling around to provide the discussed backend functionality to xlogdump (StringInfo atop PQExpBuffer and elog_start/elog_finish), the following items still need work:
1. rmgr tables We're linking rmgr.c so that we can obtain the appropriate rm_desc function pointer for each rmgr. However the table also includes the rm_redo, startup, etc function pointers, which the linker wants resolved at xlogdump link time. The idea I have to handle this is to use a macro similar to PG_KEYWORD: at compile time we define it differently on xlogdump than on backend, so that the symbols we don't want are hidden. 2. ereport() functionality Currently the xlogreader.c I'm using (the latest version posted by Andres) has both elog() calls and ereport(). I have provided trivial elog_start and elog_finish implementations, which covers the first. I am not really sure about implementing the whole errstart/errfinish stack, because that'd be pretty duplicative, though I haven't tried. The other alternative suggested elsewhere is to avoid elog/ereport entirely in xlogreader.c and instead pass a function pointer for error reportage. The backend would normally use ereport(), but xlogdump could do something simple with fprintf. I think that would end up being cleaner overall. 3. timestamptz_to_str xact_desc uses this, which involves a couple of messy backend files (because there's palloc in them, among other problems). Alternatively we could tweak xact_desc to use EncodeDateTime (probably through some simple wrapper); given the constraints imposed on the values, that might be simpler, and we can provide a simple implementation of EncodeDateTime or of its hypothetical wrapper in xlogdump. 4. relpathbackend and pfree of its return value This is messy. Maybe we should a caller-supplied buffer instead of palloc to solve this. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
