From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Only first XLogRecData is visible to rm_desc with WAL_DEBUG |
Date: | 2014-03-24 09:29:34 |
Message-ID: | 532FFAFE.3010109@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
As we all know, when you compile with WAL_DEBUG, and enable wal_debug
GUC, you get output like this in the log for every inserted WAL record:
LOG: INSERT @ 0/5407E578: prev 0/5407E4D0; xid 0; len 32: Standby -
running xacts: nextXid 774 latestCompletedXid 771 oldestRunningXid 772;
2 xacts: 7877929 0
What I did *not* realize before is that the redo routine only gets
passed the first XLogRecData struct in the chain. Because of that, the
"xacts: 7877929 0" information above is garbage. That's probably not the
only rm_desc routine that didn't get the memo.
There are a few alternatives on how to fix that:
1. Do nothing. Add a comment somewhere explaining that rm_redo cannot
safely look at data beyond what's inserted in the first XLogRecData.
2. Reconstruct the WAL data from the XLogRecData entries in a palloc'd
buffer, and pass that to rm_redo. That would be fairly expensive, but
you probably don't care about that if you've enabled wal_debug.
3. Remove the feature altogether, so that enabling wal_debug doesn't
cause all insertions to be logged anymore (no changes to the logging
during replay). It's a lot less interesting now that we have pg_xlogdump.
Thoughts?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Swapnil Bhoite | 2014-03-24 09:53:02 | Global flag |
Previous Message | Michael Glaze | 2014-03-24 09:17:25 | New Vacancy for Permanent C# Developer in Kentish Town : ref:VAC-973549 |