On 03/25/2014 02:13 AM, Alvaro Herrera wrote:
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.
I find it useful too, but I think pg_xlogdump can serve the same purpose.
One thing missing from pg_xlogdump is the capability to keep tracking
the inserted WAL, instead of dumping to the end of WAL and stopping
there. If we add an option to pg_xlogdump to poll the WAL instead of
bailing out at an error, I think it's a good replacement.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
