Re: Enabling frontend-only xlog "desc" routines

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(dot)GE6442(at)alvh(dot)no-ip(dot)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=shortlog;h=refs/heads/xlogreader_v3

> > 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?

Its not like thats something that annot be changed should an actual
usecase emerge.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services