What should I disable? Corrupt index sounds like a possible case, but how do I fix this? EXPLAIN ANALYZE select * from cubesocialnetwork.tmp_autenticazionesocial where idautenticazionesocial = 1622 "Index Scan using tmpautenticazione on tmp_autenticazionesocial (cost=0.00..8.27 rows=1 width=530) (actual time=0.078..0.081 rows=1 loops=1)" " Index Cond: (idautenticazionesocial = 1622)" "Total runtime: 0.128 ms" On 07/10/2014 00:15, Jim Nasby wrote: > On 10/5/14, 10:06 AM, Andy Colson wrote: >> On 10/05/2014 10:00 AM, Adrian Klaver wrote: >>> On 10/05/2014 07:37 AM, Tim Mickelson wrote: >>>> Sorry about that, the precise version is: "PostgreSQL 9.1.9 on >>>> x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red >>>> Hat >>>> 4.4.7-3), 64-bit" >>> >>> Well 9.1 is at .14 now, so on general principles it would be a good >>> idea to upgrade. That being said I do not see anything in the >>> release notes from .10 to .14 that applies. Though to be truthful I >>> did not read every line. Before upgrading you could try what Andy >>> suggested which is to REINDEX(tmpautenticazione). See here for the >>> REINDEX caveats, and a way to INDEX CONCURRENTLY: >>> >>> http://www.postgresql.org/docs/9.1/interactive/sql-reindex.html >>> >>>> >>>> >> >> I thought .11 sounded like a good candidate. Especially the part: >> >> allowing tuples to escape freezing, causing those rows to become >> invisible once 2^31 transactions have elapsed > Those rows should then be invisible to the FK checks as well, so I > don't think that's it. > > My guess is also on a corrupted index. A quick test would be to > disable index scans and try the delete again (use EXPLAIN ANALYZE to > make sure the delete is using a sequential scan). If that doesn't > work, post EXPLAIN ANALYZE output for the commands you're running that > generate this error. > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
