I found this patch in my local repo that I wrote some weeks or months
ago while debugging some XLog corruption problem: it was difficult to
pinpoint what XLog record in a long sequence of WAL files was causing a
problem, and the displaying the prev pointer in errcontext made finding
it much easier -- I could correlate it with pg_xlogdump output, I think.
Anyone sees a reason not to apply this or something like it?
(As I recall, we eventually found out that the underlying issue was that
two postmasters shared one data area over NFS and were overwriting one
another's WAL files, or something like that. But this was some time ago
so I could be mistaken that it's the same case.)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
commit 835e7b3c62590574e529558493c50fbfb5a85d6c
Author: Alvaro Herrera <alvhe...@alvh.no-ip.org>
Date: Tue Apr 14 12:41:11 2015 -0300
show prev in errcontext
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2580996..36dc422 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -10389,7 +10389,10 @@ rm_redo_error_callback(void *arg)
initStringInfo(&buf);
xlog_outdesc(&buf, record);
- errcontext("xlog redo %s", buf.data);
+ errcontext("xlog redo (prev %X/%X) %s",
+ (uint32) (XLogRecGetPrev(record) >> 32),
+ (uint32) (XLogRecGetPrev(record)),
+ 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
