On Wednesday, November 28, 2012 12:17 AM Alvaro Herrera wrote: > I mentioned the remaining issues in a previous email (see message-id > 20121025161751.ge6...@alvh.no-ip.org). Attached is a patch that enables > xlogdump to #include xlog_internal.h by way of removing that file's > inclusion of fmgr.h, which is problematic. I don't think this should be > too contentious.
I have tried to go through Xlogdump patch provided in mail chain of message-id provided. It seems there is no appropriate file/function header which makes it little difficult to understand the purpose. This is just a suggestion and not related to your this mail. > The other interesting question remaining is what to do about the rm_desc > function in rmgr.c. We're split between these two ideas: > > 1. Have this in rmgr.c: > > #ifdef FRONTEND > #define RMGR_REDO_FUNC(func) NULL > #else > #define RMGR_REDO_FUNC(func) func > #endif /* FRONTEND */ > > and then use RMGR_REDO_FUNC() in the table. > > > 2. Have this in rmgr.c: > > #ifndef RMGR_REDO_FUNC > #define RMGR_REDO_FUNC(func) func > #endif > > And then have the xlogdump Makefile use -D to define a suitable > RMGR_REDO_FUNC. > What I understood is that as there is only a need of rm_desc function in xlogdump, so we want to separate it out such that it can be easily used. In Approach-1, define for some of functions (redo, startup, cleanup,..) as NULL for frontends so that corresponding functions for frontends become hidden. In Approach-2, frontend (in this case Xlogdump) need to define value for that particular Macro by using -D in makefile. If my above thinking is right, then I think Approach-2 might be better as in that Frontend will have more flexibility if it wants to use some other functionality of rmgr. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
