Maxim Boguk <maxim.boguk@xxxxxxxxx> writes: > There is some funny results: > hh=# VACUUM verbose agency_statistics_old; > INFO: vacuuming "public.agency_statistics_old" > INFO: index "agency_statistics_pkey" now contains 0 row versions in 605 > pages > DETAIL: 0 index row versions were removed. Wow. That seems to blow my theory to small pieces. If the index contains no entries then it shouldn't be causing any uniqueness check probes. But at the same time, if the index is empty then how come pgstatindex showed avg_leaf_density = 0.45 ? > May be I should use pageinspect addon to see an actual index pages content? That or pg_filedump would be interesting. But your experiments with adding data from the other table will probably have produced some new index entries, which will confuse the situation. Did you save a physical copy of the index before that? Another idea is to attach to the backend with gdb, set a breakpoint at errfinish, and get a stack trace from the point of the "could not read block" error. That would show definitively if this is coming from a uniqueness check or something else entirely. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
