Robert Haas wrote: > On Mon, Mar 24, 2014 at 7:14 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
