Re: Only first XLogRecData is visible to rm_desc with WAL_DEBUG

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(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 18:05:23
Message-ID: 20140325180523.GA26658@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)vmware(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-25 18:58:54 Re: Still something fishy in the fastpath lock stuff
Previous Message Andres Freund 2014-03-25 18:03:35 Re: Minimum supported version of Python?