>>>>> "tsuraan" == tsuraan <tsuraan@gmail.com> writes:
tsuraan> Quite a bit there, but the region around there does look weird:
tsuraan> 00001d40 00 00 00 00 00 00 00 00 00 01 00 00 ff ff ff ff |................|
tsuraan> 00001d50 00 00 00 00 f4 06 00 00 01 00 00 00 6c 65 2e 73 |............le.s|
tsuraan> 00001d60 6f 00 70 79 63 00 65 2e 00 00 00 00 00 00 00 00 |o.pyc.e.........|
tsuraan> 00001d70 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
tsuraan> 00001d80 00 00 00 00 00 00 00 00 3a 00 00 ff 00 00 00 00 |........:.......|
tsuraan> 00001d90 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 |................|
tsuraan> 00001da0 28 f8 12 00 00 00 00 00 00 00 00 00 00 00 00 00 |(...............|
tsuraan> 00001db0 0d 00 0d 80 0a 29 20 00 00 00 00 00 03 30 00 00 |.....) ......0..|
tsuraan> 00001dc0 74 65 6d 70 6c 61 74 65 30 00 00 00 00 00 00 00 |template0.......|
tsuraan> 00001dd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
tsuraan> The le.s that you noticed actually looks like le.so, and then
tsuraan> there's a pyc and an "e." after it (null-separated).
That's quite odd.
But it looks like the data here is corrupt from offset 1d5c for the next
64 bytes (+/- 4 bytes, maybe, but much more likely to be exactly 64).
That's not something I recall seeing before, but some kind of hardware
corruption issue couldn't be ruled out. I don't suppose you have data
checksums enabled?
The "cache lookup failed" error is caused by the fact that the column
_after_ dattablespace, i.e. datacl, is also corrupt (the database must
have had a non-null ACL with an additional grant to exactly one role
going by the layout of records).
tsuraan> Also weird is that there are six different sections
tsuraan> describing(?) template1:
That's not really weird - the pg_database rows can get updated, e.g.
from grant/revoke, and autovacuum usually won't kick in for a long time
because the table is so tiny. So some number of old dead row versions is
expected - likewise for your own db.
--
Andrew (irc:RhodiumToad)