>> Sinto muito, mas essa implementação pode ter um efeito colateral. Duas >> transações concorrentes podem "catar" o mesmo valor. O SELECT... FOR >> UPDATE não impede a leitura do registro. > > Impedem sim. Se usados corretamente. O valor do contador deve ser > obtido através de um único meio para que o FOR UPDATE funcione, como o > uso de uma função com citei no exemplo. Só não impede que um outro > SELECT *sem* a cláusula FOR UPDATE leia o mesmo registro. O uso deste
E era disso que eu estava falando. >> Pode ocorrer um ROLLBACK automático na transação que chegar por último >> na hora fizer o UPDATE da sua função. Se a aplicação não tratar esse >> ROLLBACK (e tentar novamente até conseguir sucesso no COMMIT) isso >> pode se tornar uma bola de neve e um catastrófico "lock geral" numa >> aplicação com muita concorrência. >> > > Pode ocorrer o estouro de tempo de transação se a variável > STATEMENT_TIMEOUT estiver configurada com um valor diferente de zero > [2], mas isso certamente apresentaria um erro no client que deve ser statement_timeout não é "estouro do tempo de transação". Pode ser traduzido livremente como "estouro do tempo de consulta", como o próprio link indicado explica. Transações não tem timeout definido no PostgreSQL e, por isso, transações não finalizadas ficam no estado "idle <in transaction>", uma das coisas que sua função pode fazer, o que é péssimo. Sem contar que você pode colocar uma conexão como "blocked". > Nos quesitos facilidade de implementação e desempenho, as sequencias > são imbatíveis. Eu mesmo tenho experiências práticas com isso. Mas > reforço que para alguns casos quando os contadores precisam seguir uma > sequência infalível, ou seja, sem *pular* um único valor, usar uma > SEQUENCE não é o mais indicado. E por falar em bancos de dados sério, É perfeitamente possível implementar uma aplicação usando sequências sem pular números. Imagine um emissor de notas fiscais, sequenciais, num POS. É uma conexão com o banco, uma aplicação single thread, não haverá "pulo". Numa aplicação distribuída, não havendo ROLLBACK, não haverá "pulo" também. E se, alguém fizer o ROLLBACK, pode-se ter uma sub-rotina de contorno que vai colocar o valor inutilizado da sequência numa tabela pool. []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
