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 $@$(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 <sn...@uptime.jp> Uptime Technologies, LLC. http://www.uptime.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
