On Wednesday, November 28, 2012 12:17 AM Alvaro Herrera wrote:
> I mentioned the remaining issues in a previous email (see message-id
> 20121025161751.GE6442@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.
