Re: Enabling frontend-only xlog "desc" routines - Mailing list pgsql-hackers

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