Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG

On 03/25/2014 08:05 PM, Andres Freund wrote:
> On 2014-03-25 10:49:54 -0700, Robert Haas wrote:
>> On Tue, Mar 25, 2014 at 12:30 AM, Heikki Linnakangas
>> <hlinnakangas@vmware.com> wrote:
>>>>> 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.
>>
>> Well, one nice thing about wal_debug is that the WAL is at that point
>> still associated with the session that generated it.  But I grant
>> that's not a huge issue.  How much work are we talking about to fix
>> this, though?
>
> It's not entirely trivial, we'd essentially need to copy the loop in
> CopyXLogRecordToWAL(). And do so while still holding the
> WALInsertLock().

Oh, no, there's no need to do it while holding WALInsertLock. It's quite
trivial, actually, see attached. So it's not difficult to fix this if we
want to.

I just committed a patch to add a -f/--follow flag to pg_xlogdump. That
seems very handy, even if we decide to fix the wal_debug code. It
doesn't require compiling with wal_debug, and pg_xlogdump allows
filtering by rmgr id etc.

- Heikki