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
