Michael Glenn <mike@mglenn.com> writes:
> [ pg_filedump output ]
Looking at this, I'm kind of wondering whether you didn't have a
transaction ID wrap after all. You've got a number of rows here that
appear to have been touched by quite large transaction numbers,
for instance:
> Item 8 -- Length: 80 Offset: 7508 (0x1d54) Flags: USED
> OID: 109529120 CID: min(0) max(0) XID: min(24597178) max(0)
^^^^^^^^
> Item 9 -- Length: 89 Offset: 6896 (0x1af0) Flags: USED
> OID: 133213920 CID: min(0) max(0) XID: min(34149469) max(0)
^^^^^^^^
and they're marked committed too, which means that some other
transaction agreed that that XID had gotten committed. You sure
that there's not anything you've forgotten to tell us about past
sins with pg_log? There's no way that XID 34149469 could have
been marked committed unless pg_log were at least 8.5 megabytes.
What I think you might be able to do as a band-aid solution is to force
up the current-XID counter, which lives in, hmm, $PGDATA/pg_variable in
7.0.*. Without the former contents of pg_log this will not give you a
completely accurate reconstruction of your data, but it should be good
at least back to the last vacuum, which is a lot better than nothing
(assuming you were more religious about vacuuming than backups ;-)).
What do you get from "od -x pg_variable"?
regards, tom lane
