On 8 Jan 2010, at 18:28, Tom Lane wrote: >> # select attachment_id from attachment where ctid = '(603713,1)'; >> attachment_id >> --------------- >> 15460683 >> (1 row) > >> # select attachment_id from attachment where attachment_id = 15460683; >> attachment_id >> --------------- >> (0 rows) > > Oh, so the row *is* there. What the above says is that you have a > corrupt index on attachment_id, which you should be able to fix via > REINDEX. However, I'm still a bit confused, because corrupt indexes > don't normally cause a problem for pg_dump (which is just doing SELECT * > or COPY, so the index wouldn't be consulted). Are the dumps you are > talking about perhaps made with something other than pg_dump? Would pg_dump still not consult the index if someone sets enable_seqscan=false in the config file? To Konrad: Did you turn off seqscans in the postgres.conf? Could you try a "REINDEX TABLE attachment" again in case you somehow reindexed the wrong index or table? You seem to know what you're doing, but just in case we missed something as this is strange enough to have even the devs scratching their heads. The rows are there, so it _has_ to be an index or a transaction visibility issue... Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:737,4b47b35810731946694119! -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
