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

On 2012-12-11 15:55:35 +0200, Heikki Linnakangas wrote:
> 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 that I have read some of that code, I am currently unsure how the
current implementation of this can cooperate with translation, even when
used from the backend?

Greetings,

Andres Freund

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