show xl_prev in xlog.c errcontext
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
Attachments:
errctx-prev.patchtext/x-diff; charset=us-asciiDownload
commit 835e7b3c62590574e529558493c50fbfb5a85d6c
Author: Alvaro Herrera <alvherre@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);
}
On 04/15/2015 11:35 PM, Alvaro Herrera wrote:
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.
Seems like a good idea, but why print the prev pointer, and not the
location of the record itself?
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Apr 16, 2015 at 3:25 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 04/15/2015 11:35 PM, Alvaro Herrera wrote:
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.Seems like a good idea, but why print the prev pointer, and not the location
of the record itself?
And both?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier wrote:
On Thu, Apr 16, 2015 at 3:25 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 04/15/2015 11:35 PM, Alvaro Herrera wrote:
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.Seems like a good idea, but why print the prev pointer, and not the location
of the record itself?
Makes sense -- pushed that way.
And both?
I couldn't see much point of doing this, so I didn't. If you have a
rationale for it, let's hear it.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Apr 5, 2016 at 6:14 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Michael Paquier wrote:
And both?
I couldn't see much point of doing this, so I didn't. If you have a
rationale for it, let's hear it.
Now that I think on it, it does not actually matter to print both.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers