Re: [PATCH] XLogReader v2 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] XLogReader v2
Date
Msg-id 201207230919.57301.andres@2ndquadrant.com
Whole thread Raw
In response to Re: [PATCH] XLogReader v2  (Satoshi Nagayasu <snaga@uptime.jp>)
Responses Re: [PATCH] XLogReader v2  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On Thursday, July 19, 2012 07:18:08 PM Satoshi Nagayasu wrote:
> I agree with that we need more sophisticated way to share the code
> between the backend and several utilities (including xlogdump),
> but AFAIK, a contrib module must allow to be built *without* the core
> source tree.
I don't think thats reasonable. The amount of code duplication required to 
support that usecase is just not reasonable. Especially if you want to support 
pre 9.3 and 9.3+.

> So, I agree with that we need another way to share the code
> between the backend and the related utilities. Any good ideas?
Well, the primary patch in the above email was infrastructure to at least make 
reading xlog possible without much internal knowledge. But that will still 
leave the debugging routines... Which imo already is too much.

> It would mean that the users using older major version could not take
> advantage of new features and enhancements of the latest xlogdump,
> but it's not what I wanted, actually.
I personally don't see that as a big problem. If xlogdump really reuses the 
normal infrastructure of the server the amount of code you need to backport is 
*way* much smaller should it ever be actually needed.

> Any contrib module must be able to be built with only the header files
> and the shared libraries when using PGXS. So, it could not assume
> that it has the core source tree. (If we need to assume that, I think
> xlogdump needs to be put into the core/bin directory.)
We possibly could get away by defining an extra .a containing the necessary 
object files. Not nice, but...
Imo it *should* be in src/bin though.

Greetings,

Andres

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


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
Next
From: Alexander Korotkov
Date:
Subject: Re: SP-GiST for ranges based on 2d-mapping and quad-tree