"O'Shea, Brendan" <boshea@xxxxxxxxxx> writes:
>> "Lane, Tom" <tgl@xxxxxxxxxxxxx> writes:
>> Ugh. Does it work if you do
>> export PGOPTIONS="--ignore_system_indexes=1"
> I tried that, but unfortunately pg_dump still fails to run and the error
> message is identical to previous attempts.
Huh. So it's not index corruption then. Table corruption is still a
possibility but it seems likely that you'd be getting other errors
during the seqscan that looks for the rows. This suggests that the rows
actually disappeared from pg_attribute, which is a bit hard to credit.
The only mechanisms I can think of are that VACUUM decided they were
dead or something physically truncated the table. The latter would
probably have zapped a lot of other rows though.
Have you checked to see if pg_roles is the only relation with this
problem? Try
select c.relname from pg_class c left join pg_attribute a
on a.attrelid = c.oid and a.attnum > 0
group by c.oid,c.relname,c.relnatts having count(*) != c.relnatts;
> Any suggestions for additional logging we might turn on to help
> determine the cause of this issue?
Maybe VACUUM VERBOSE on pg_attribute? Although you'd have to get lucky
enough to catch the time that it zapped the rows, if that's what the
problem is.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
