Re: [PATCH 02/14] Add support for a generic wal reading facility dubbed XLogReader

I've been molding this patch for a while now, here's what I have this
far (also available in my git repository).

The biggest change is in the error reporting. A stand-alone program that
wants to use xlogreader.c no longer has to provide a full-blown
replacement for ereport(). The only thing that xlogreader.c used
ereport() was when it encounters an invalid record. And even there we
had the emode_for_corrupt_record hack. I think it's a much better API
that XLogReadRecord just returns NULL on an invalid record, and an error
string, and the caller can do what it wants with that. In xlog.c, we'll
pass the error string to ereport(), with the right emode as determined
by emode_for_corrupt_record. xlog.c is no longer concerned with
emode_for_corrupt_record, or error levels in general.

We talked about this earlier, and Tom Lane argued that "it's basically
insane to imagine that you can carve out a non-trivial piece of the
backend that doesn't contain any elog calls."
(http://archives.postgresql.org/pgsql-hackers/2012-09/msg00651.php), but
having done just that, it doesn't seem insane to me. xlogreader.c really
is a pretty well contained piece of code. All the complicated stuff that
contains elog calls and pallocs and more is in the callback, which can
freely use all the normal backend infrastructure.

Now, here's some stuff that still need to be done:

* A stand-alone program using xlogreader.c has to provide an
implementation of tliInHistory(). Need to find a better way to do that.
Perhaps "#ifndef FRONTEND" the tliInHistory checks in xlogreader.

* In xlog.c, some of the variables that used to be statics like
readFile, readOff etc. are now in the XLogPageReadPrivate struct. But
there's still plenty of statics left in there - it would certainly not
work correctly if xlog.c tried to open two xlog files at the same time.
I think it's just confusing to have some stuff in the
XLogPageReadPrivate struct, and others as static, so I think we should
get rid of XLogPageReadPrivate struct altogether and put back the static
variables. At least it would make the diff smaller, which might help
with reviewing. xlog.c probably doesn't need to provide a "private"
struct to xlogreader.c at all, which is okay.

* It's pretty ugly that to use the rm_desc functions, you have to
provide dummy implementations of a bunch of backend functions, including
pfree() and timestamptz_to_str(). Should find a better way to do that.

* It's not clear to me how we'd handle translating the strings in
xlogreader.c, when xlogreader.c is used in a stand-alone program like
pg_xlogdump. Maybe we can just punt on that...

* How about we move pg_xlogdump to contrib? It doesn't feel like the
kind of essential tool that deserves to be in src/bin.

- Heikki