2018-04-09 18:23 GMT-03:00 Peter Geoghegan <pg@xxxxxxx>: > > On Mon, Apr 9, 2018 at 7:01 AM, Tomas Vondra > <tomas.vondra@xxxxxxxxxxxxxxx> wrote: > > The bigger question is whether this can actually detect the issue. If > > it's due to an storage issue, then perhaps yes. But if you only see > > multixact issues consistently and nothing else, it might easily be a > > PostgreSQL bug (in which case the checksum will be correct). > > You can also run amcheck. Get the version targeting earlier Postgres > releases off Github (there are packages for most Linux systems). This > can verify that the heap is consistent with indexes. > > -- > Peter Geoghegan Hi Peter, I ran amcheck in all index of a table and I only get empty returns. I did some tests: production=# reindex table fn06t; REINDEX production=# vacuum verbose fn06t; INFO: vacuuming "public.fn06t" ERROR: found multixact 76440919 from before relminmxid 122128619 production=# select count(*),sum(fn06vrtitu) from fn06t; count | sum ---------+----------------- 2592363 | 4833603148.1172 (1 row) #createdb freshdb #pg_dump -t fn06t production | psql freshdb freshdb=# select count(*),sum(fn06vrtitu) from fn06t; count | sum ---------+----------------- 2592363 | 4833603148.1172 (1 row) psql -c "select * from fn06t order by <PKEY>" production > multixact_error_fn06t.txt psql -c "select * from fn06t order by <PKEY>" freshdb > freshdb_fn06t.txt diff points no differences in files and md5sum produces the same hash. The question is: if a dump can read the table "correctly", why a CLUSTER/vacuum full stops while reading them? Best regards, Alexandre
