Sérgio Mariano Dias escreveu: > Quando uma aplicação faz um “select for update” e essa aplicação cai por > algum motivo não liberando o “select for update”. Como garantir que > esses dados serão liberados? Existe algum parâmetro de configuração no > banco (timeout) para o loock feito? > O comportamento quando uma transação cai é que a conexão com o banco de dados seja finaliza e, assim, todo o contexto (transação envolvida) seja terminado (nesse caso desfeito -- aka ROLLBACK). Em alguns cenários (principalmente utilizando aquele outro sistema operacional), isso _não_ acontece (não me pergunte o porquê).
Nesse caso, me vem a mente três alternativas: (i) monitorar esse casos (fazendo consultas regulares a pg_locks e pg_stat_activity) e cancelar conexões perdidas (de acordo com o tempo e/ou consulta?), (ii) utilizar a cláusula NOWAIT [1] e tratar a possível falha da transação porque o _lock_ *não* foi adquirido imediatamente ou (iii) utilizar o parâmetro statement_timeout [2] (cancela comandos que demoram mais do que um determinado tempo). A opção (ii) funciona bem quando não temos tanta concorrência em registros por diferentes sessões. Use a alternativa (iii) com moderação, pois consultas demoradas do seu sistema ou mesmo rotinas de manutenção podem ser canceladas por esse parâmetro. Um parâmetro [3] para cancelar comandos caso um _lock_ demore mais do que um determinado tempo para serem adquirido foi proposto para 8.5/9.0(?) mas ainda não se sabe se estará na próxima versão. [1] http://www.postgresql.org/docs/8.4/static/sql-select.html#SQL-FOR-UPDATE-SHARE [2] http://www.postgresql.org/docs/8.4/static/runtime-config-client.html [3] https://commitfest.postgresql.org/action/patch_view?id=262 -- Euler Taveira de Oliveira http://www.timbira.com/ _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
