Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG
Date
Msg-id 20140325180523.GA26658@alap3.anarazel.de
Whole thread Raw
In response to Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
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().

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Minimum supported version of Python?
Next
From: Tom Lane
Date:
Subject: Re: Still something fishy in the fastpath lock stuff