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
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
