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

Heikki Linnakangas wrote:
> On 15.11.2012 16:50, Alvaro Herrera wrote:

> >I worked a bit more on that patch of yours, but I neglected to submit
> >it.  Did you have something in particular that you wanted changed in it?
> 
> Off the top of my head, there were a two open items with the patch
> as I submitted it:
> 
> 1. Need to make sure it's easy to compile outside backend code. So
> that it's suitable for using in an xlogdump contrib module, for
> example.
> 
> 2. do something about error reporting. In particular, xlogreader.c
> should not call emode_for_corrupt_record(), but we need to provide
> for that functionlity somehow. I think I'd prefer xlogreader.c to
> not ereport() on a corrupt record. Instead, it would return an error
> string to the caller, which could then decide what to do with it.
> Translating the messages needs some thought, though.
> 
> Other than those, and cleanup of any obsoleted comments etc. and
> adding docs, I think it was good to go.

Thanks.  I was toying with the idea that xlogreader.c should return a
status code to the caller, and additionally an error string; not all
error cases are equal.

Most of what I did (other than general cleanup) was moving some xlog.c
global vars into a private_data struct for xlogreader.c to pass around;
one problem I had was deciding what to do with curFileTLI and
LastFileTLI (IIRC), because they are used outside of the reader module
(they were examined after recovery finished).

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services