Bom dia!!!
Em 5 de setembro de 2013 09:07, Matheus de Oliveira < matioli.math...@gmail.com> escreveu: > > 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): > Exato, é um JOIN entre estas tabelas. O vacuum não está bloqueado (waiting = FALSE) e em pg_locks granded=TRUE. Não tenho prepared statements bloqueadas neste banco. O mais estranho é que não consigo "matar", conforme descrevi acima. > 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: > Não tem nada lá. > > ROLLBACK PREPARED 'foo'; > Já havia feito as duas análises: O vacuum não esta bloqueado e também não há nada nesta view. > > 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. > Concordo, porém nem tudo é tão simples :( > > > > 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 > > Abraços -- JotaComm http://jotacomm.wordpress.com
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
