Bom dia pessoal! Rodei um script .sh que tem um loop que gera um arquivo txt (com 396 registros) e depois faz copy do mesmo para a base de dados, "n" vezes.
Coloquei o mesmo script rodando em duas instancias concorrentes, e em alguns momentos o banco trava fazendo o copy, mas não sei onde buscar informação que explique o ocorrido. No caso explicado abaixo, o erro ocorreu na sexta vez q estava rodando o loop, mas as vezes não acontece. No momento que estava travado rodei as consultas abaixo mas não consegui concluir nada: BaseReiterado=# select * from pg_stat_activity ; datid | datname | procpid | usesysid | usename | current_query | waiting | query_start | backend_start | client_addr | client_port --------+---------------+---------+----------+----------------+-----------------------------------------------------------+---------+-------------------------------+-------------------------------+-------------+------------- 181828 | BaseReiterado | 7771 | 16384 | root | <IDLE> | f | 2010-07-27 20:11:47.814735-03 | 2010-07-27 19:34:45.357057-03 | | -1 181828 | BaseReiterado | 7772 | 16384 | root | select * from pg_stat_activity ; | f | 2010-07-27 20:42:48.278407-03 | 2010-07-27 20:22:23.044175-03 | | -1 181828 | BaseReiterado | 3077 | 17690 | user_reiterado | COPY tab_reiterados FROM '/root/preenche_sql/saiday.txt'; | f | 2010-07-27 20:27:44.193394-03 | 2010-07-27 20:27:44.192093-03 | | -1 181828 | BaseReiterado | 32033 | 17690 | user_reiterado | COPY tab_reiterados FROM '/root/preenche_sql/saidax.txt'; | f | 2010-07-27 20:27:40.727867-03 | 2010-07-27 20:27:40.726598-03 | | -1 (4 rows) BaseReiterado=# select * from pg_locks; locktype | database | relation | page | tuple | transactionid | classid | objid | objsubid | transaction | pid | mode | granted ---------------+----------+----------+------+-------+---------------+---------+-------+----------+-------------+-------+------------------+--------- relation | 181828 | 181832 | | | | | | | 1252004 | 32033 | RowExclusiveLock | t relation | 181828 | 181838 | | | | | | | 1252006 | 3077 | RowExclusiveLock | t relation | 181828 | 181840 | | | | | | | 1252004 | 32033 | RowExclusiveLock | t transactionid | | | | | 1252232 | | | | 1252232 | 7772 | ExclusiveLock | t transactionid | | | | | 1252004 | | | | 1252004 | 32033 | ExclusiveLock | t relation | 181828 | 181832 | | | | | | | 1252006 | 3077 | RowExclusiveLock | t relation | 181828 | 181838 | | | | | | | 1252004 | 32033 | RowExclusiveLock | t relation | 181828 | 181840 | | | | | | | 1252006 | 3077 | RowExclusiveLock | t relation | 181828 | 10328 | | | | | | | 1252232 | 7772 | AccessShareLock | t transactionid | | | | | 1252006 | | | | 1252006 | 3077 | ExclusiveLock | t relation | 181828 | 181841 | | | | | | | 1252006 | 3077 | RowExclusiveLock | t relation | 181828 | 181839 | | | | | | | 1252004 | 32033 | RowExclusiveLock | t relation | 181828 | 181841 | | | | | | | 1252004 | 32033 | RowExclusiveLock | t relation | 181828 | 181839 | | | | | | | 1252006 | 3077 | RowExclusiveLock | t (14 rows) É possível concluir alguma coisa? Se não, vcs podem me dar alguma dica pra investigação? obs: sei q é absurdo, mas estou rodando em um postgres 7.2. Pelo q me falaram aqui na empresa, a evolucao para outra versao é custosa, visto que envolve kernel do linux e necessidade de recompilacao de todos os modulos da aplicacao (que eh gigante, escrita em C/C++) e reteste de tudo. Desde já, agradeço possiveis comentarios. []'s Fabio Barros
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral