Darren Reed <darrenr+postgres@fastmail.net> writes:
> See if the attached helps.
Well, here's the entry for the index it's trying to load:
> Item 12 -- Length: 164 Offset: 6224 (0x1850) Flags: USED
> XMIN: 1 CMIN: 0 XMAX: 667033 CMAX|XVAC: 6 OID: 2701
> Block Id: 7 linp Index: 3 Attributes: 27 Size: 36
> infomask: 0x0511 (HASNULL|HASOID|XMIN_COMMITTED|XMAX_COMMITTED)
> t_bits: [0]: 0xff [1]: 0xff [2]: 0xff [3]: 0x01
> 1850: 01000000 00000000 992d0a00 06000000 ........�-......
> 1860: 00000700 03001b00 110524ff ffff0100 ..........$.....
> 1870: 8d0a0000 70675f74 72696767 65725f74 �...pg_trigger_t
> 1880: 6772656c 69645f74 676e616d 655f696e grelid_tgname_in
> 1890: 64657800 00000000 00000000 00000000 dex.............
> 18a0: 00000000 00000000 00000000 00000000 ................
> 18b0: 00000000 0b000000 00000000 0a000000 ................
> 18c0: 93010000 8d0a0000 00000000 02000000 �...�...........
> 18d0: 00004040 00000000 00000000 00006900 ..@@..........i.
> 18e0: 02000000 00000000 00000000 00000000 ................
> 18f0: 00000000 ....
So it's been updated, as is to be expected if you just reindexed
everything, and the updated row went into block 7. Only problem
is, there is no block 7 :-( ... pg_class ends at block 6.
There are 25 other entries that have update links pointing into
block 7, all of them with very recent XMAX (667033 to 667072,
and we saw you crashed at XID 669090). So this is consistent
with the idea that your REINDEX was responsible for updating
all those rows. But what happened to block 7?
What I am suspicious of is that you had an occurrence of the
apparent block-zeroing problem that took out block 7, and shortly
thereafter vacuum came along, found nothing in block 7, and truncated
it away. If this happened then there should be something about
relation "pg_class" page 7 is uninitialized --- fixing
in the postmaster log; this would be after the REINDEX and before
the crash, so I'm hoping it's still there? Did you do a manual
vacuum after reindexing, or maybe autovacuum is on?
regards, tom lane
