From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG |
Date: | 2014-03-25 07:30:22 |
Message-ID: | 5331308E.4000607@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2014-03-25 08:35:18 | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Previous Message | Ashutosh Bapat | 2014-03-25 05:05:05 | Re: using arrays within structure in ECPG |