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
<hlinnakan...@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
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index b573185..3b28905 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -1262,8 +1262,20 @@ begin:;
xlog_outrec(&buf, rechdr);
if (rdata->data != NULL)
{
+ StringInfoData recordbuf;
+
+ /*
+ * We have to piece together the WAL record data from the
+ * XLogRecData entries, so that we can pass it to the rm_desc
+ * function as one contiguous chunk.
+ */
+ initStringInfo(&recordbuf);
+ for (;rdata != NULL; rdata = rdata->next)
+ appendBinaryStringInfo(&recordbuf, rdata->data, rdata->len);
+
appendStringInfoString(&buf, " - ");
- RmgrTable[rechdr->xl_rmid].rm_desc(&buf, rechdr->xl_info, rdata->data);
+ RmgrTable[rechdr->xl_rmid].rm_desc(&buf, rechdr->xl_info, recordbuf.data);
+ pfree(recordbuf.data);
}
elog(LOG, "%s", buf.data);
pfree(buf.data);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
