On 03/25/2014 02:13 AM, Alvaro Herrera wrote:
> 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.
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
