Re: [PATCH] XLogReader v2

2012/07/19 19:29, Andres Freund wrote:
> Hi,
>
> Attached is v2 of the patch.
>
> Changes are:
> * more comments
> * significantly cleaned/simpliefied coded
> * crc validation
> * addition of XLogReaderReadOne
>
> Definitely needed are:
> * better validation of records
> * customizable error handling
>
> The first is just work that needs to be done, nothing complicated.
> The second is a bit more complicated:
> - We could have an bool had_error and a static char that contains the error
> message, the caller can handle that as wanted
> - We could have a callback for error handling
>
> I think I prefer the callback solution.
>
>
> The second attached patch is a very, very preliminary xlog dumping utility
> which currently is more of a debugging facility (as evidenced by the fact that
> it needs and existing /tmp/xlog directory for writing out data) for the
> XLogReader. It reuses the builtin xlog dumping logic and thus has to link with
> backend code. I couldn't find a really sensible way to do this:
>
> xlogdump: $(OBJS) $(shell find ../../backend ../../timezone -name
> objfiles.txt|xargs cat|tr -s " " "\012"|grep -v /main.o|sed 's/^/..\/..\/..
> $(CC) $(CFLAGS) $^ $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $(at)$(X)
>
> Perhaps somebody has a better idea? I think having an xlogdump utility in
> core/contrib would be a good idea now that it can be done without a huge
> amount of code duplication. I plan to check Satoshi-san's version of xlogdump
> whether I can crib some of the commandline interface and some code from there.

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.

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

On the other hand, I have an issue to improve maintainancability of
the duplicated code at the xlogdump project.

Gather all the code which has been copied from the core.
https://github.com/snaga/xlogdump/issues/26

So, I agree with that we need another way to share the code
between the backend and the related utilities. Any good ideas?

I have one more concern for putting xlogdump into the core.

xlogdump is intended to deliver any new features and enhancements
to all the users who are using not only the latest major version,
but also older major versions maintained by the community, because
xlogdump must be a quite important tool when DBA needs it.

In fact, the latest xlogdump is now supporting 5 major versions,
from 8.3 to 9.2.
https://github.com/snaga/xlogdump/blob/master/README.xlogdump

But AFAIK, putting xlogdump into the core/contrib would mean that
a source tree of each major version could not have a large modification
after each release (or each code freeze, actually).

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.

Regards,

>
> Greetings,
>
> Andres
>
>
>
>

--
Satoshi Nagayasu <snaga(at)uptime(dot)jp>
Uptime Technologies, LLC. http://www.uptime.jp