Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I looked at Andres' patch and the general idea is rather horrible: it
> links all backend files into the output executable. This is so that the
> *_desc functions can be used from their respective object files, which
> obviously have a lot of requirements for backend infrastructure.
Check.
> So it is my intention to split out the desc() functions out of their
> current files, into their own file, allowing xlogdump to link against
> that and not be forced to link the rest of the backend.
Meh. Can we compromise on one file per xlog rmgr? I don't much care
for the "one big file" idea.
> To solve the stringinfo problem, we would provide a separate
> implementation of it, one that doesn't depend on palloc and elog.
Shim on top of PQExpBuffer seems like the way to go.
An alternative thing that might be worth considering before you go all
in on this is whether the xlogdump functionality shouldn't just be part
of the regular server executable, ie you'd call it with
postgres --xlogdump <arguments>
and the only extra code needed is two lines for another redirect in
main.c. We've already done that for things like --describe-config.
This'd likely be a lot less work than getting the _desc routines to
be operable standalone ...
regards, tom lane
