On Wednesday, November 28, 2012 7:07 PM Andres Freund wrote: > On 2012-11-28 18:58:45 +0530, Amit Kapila wrote: > > 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. > > An updated version of xlogdump with some initial documentation, sensible > building, and some more is available at > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=sh > ortlog;h=refs/heads/xlogreader_v3
Oops.. looked at wrong version. > > > 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. > > I personally favor approach-1 because I cannot see any potential other > use. You basically need to have the full backend code available just to > successfully link the other functions. Running is even more complex, and > there's no real point in doing that standalone anyway, so, what for? Such functionality might be used if somebody wants to write independent test for storage engine, but not sure if such a thing (Approach-2) can be helpful. As I can see that Approach-1 has advantage, there will be no dependency in makefiles for exposing rm_desc functionality. And for Approach-2, it is unnecessary for makefile to define value if there is actually no other relevant use case for it. Can you think of any other pros-cons of both approaches, or do you think we already have sufficient reasoning to conclude on Approach-1. 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
