2013/9/4 JotaComm <jota.c...@gmail.com> > > Pessoal, > > Boa tarde!!! > > Opa. Bom dia, =D...
> Vou expor o meu problema e gostaria de saber se alguém já passou por > situação semelhante: > > Tenho um vacuum rodando em uma tabela desde o dia 2013-08-27 18:58: > 41.527238-03, no entanto a tabela não é grande: 5.428.982 - (8243 MB > incluindo indices). > > Estou achando muito estranho a demora e não encontrei nada que me > indicasse problema, porém tenho tabelas maiores e o vaccum roda > normalmente. Tentei cancelar o processo e não obtive sucesso: > > billing=# SELECT localtimestamp(0); > -[ RECORD 1 ]------------------ > timestamp | 2013-09-04 11:23:06 > > billing=# SELECT > pg_stat_activity.procpid,pg_stat_activity.current_query,pg_stat_activity.query_start > FROM pg_stat_activity WHERE pg_stat_activity.current_query ~ > 'public.mensagem' AND pg_stat_activity.procpid!=pg_backend_pid(); > -[ RECORD 1 ]-+----------------------------------------------------------- > procpid | 2738 > current_query | autovacuum: VACUUM public.mensagem (to prevent wraparound) > query_start | 2013-08-27 18:58:41.527238-03 > > billing=# SELECT pg_cancel_backend(2738); > -[ RECORD 1 ]-----+-- > pg_cancel_backend | t > > billing=# SELECT localtimestamp(0); > -[ RECORD 1 ]------------------ > timestamp | 2013-09-04 11:23:18 > > billing=# SELECT > pg_stat_activity.procpid,pg_stat_activity.current_query,pg_stat_activity.query_start > FROM pg_stat_activity WHERE pg_stat_activity.current_query ~ > 'public.mensagem' AND pg_stat_activity.procpid!=pg_backend_pid(); > -[ RECORD 1 ]-+----------------------------------------------------------- > procpid | 2738 > current_query | autovacuum: VACUUM public.mensagem (to prevent wraparound) > query_start | 2013-08-27 18:58:41.527238-03 > > Sempre que consultar a pg_stat_activity, inclua a coluna waiting. Acredito que você omitiu a principal informação para ajudarmos a resolver o problema. Outras informações: > > procpid | 2738 > relname | mensagem > current_query | autovacuum: VACUUM public.mensagem (to prevent > wraparound) > query_start | 2013-08-27 18:58:41.527238-03 > virtualtransaction | 3/301 > mode | ShareUpdateExclusiveLock > n_tup_ins | 448414 > n_tup_upd | 2665536 > n_tup_del | 0 > n_live_tup | 448375 > n_dead_tup | 1129161 > last_vacuum | > last_autovacuum | > last_analyze | > last_autoanalyze | > > Bom, apesar de *você não informar* qual foi essa última consulta, vejo que é um join entre pg_stat_activity, pg_locks e pg_stat_user_tables, e, pelo ShareUpdateExclusiveLock podemos assumir que o VACUUM está bloqueado (por favor, inclua a coluna pg_locks.granted ou pg_stat_activity.waiting para garantir). Bom, agora temos que descobrir quem está bloqueando o VACUUM, eu chutaria, pelo tempo, que você está usando "prepared transactions", por favor verifique o resultado da consulta (conectado à base em questão): SELECT * FROM pg_prepared_xacts; E verifique se alguma pode ser "matada" (provavelmente uma com o timestamp "prepared" antigo), se puder execute o seguinte para matá-la: ROLLBACK PREPARED 'foo'; Onde "foo" seria o identificador da transação, que pode ser recuperado na coluna "gid". A versão do PostgreSQL é a 9.0.4. > > Atualize imediatamente (sem desculpas) para a versão 9.0.13 (ou se puder, para a 9.2.4, mas essa não precisa do "imediatamente", =P ). A versão do SO é CentOS release 6.3 (Final). > > Também vale a pena atualizar para o 6.4, mas não vejo como algo tão crítico/urgente. Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
