Robert Haas wrote:
> On Mon, Mar 24, 2014 at 7:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 3. Remove the feature altogether, so that enabling wal_debug doesn't
> >> cause all insertions to be logged anymore (no changes to the logging
> >> during replay). It's a lot less interesting now that we have pg_xlogdump.
> >
> > I think the main use-case for rm_desc anymore is making CONTEXT lines
> > for errors reported during WAL replay. I guess that situation does not
> > have the same problem, since we've already loaded the complete WAL record.
> >
> > However, I'm not sure how easy it's going to be for WAL_DEBUG to make the
> > data look the same as the replay case: in particular, substitution of
> > full-page-images for data would be tough to predict in advance (and moving
> > the printout into the critical section seems like a bad answer).
> >
> > I'd be okay with removing WAL_DEBUG, I think, particularly in view of the
> > fact that there have been no requests to make it a compiled-by-default
> > feature.
>
> I've found WAL_DEBUG quite useful in the past, when working on
> scalability, and have indeed wished for it to be
> compiled-in-by-default.
>
> I don't know whether I'm the only one, though.
You are not. I would rather have it fixed than removed, if possible. I
don't really care too much about getting a performance hit to palloc the
records, really; being able to actually read what's happening is much
more useful.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services