>> Para bloquear registros específicos, use SELECT.... FOR UPDATE. >> Os registros ficarão bloqueados para modificação até o COMMIT ou >> ROLLBACK da transação. >> A limpeza automática não é abortada neste caso, ela apenas pulará os >> registros afetados e os tratará na próxima execução. > > Ok, mas o problema é que não posso bloquear apenas as modificações nesses > registros. não posso retorna-los em consultas. Pois imagine que os registros > ainda estão sendo atualizados para "em processamento" quando outra sessão > requisitar os registros que não estão em processamento.
Não seria mais fácil controlar isso com um campo flag, filtrado pela aplicação? Você precisa mesmo de lock pessimista? Eles são péssimos. É como se faziam locks nos arquivos DBF da década de 80. > O que estou pensando em fazer é criar uma tabela sem dados que controlará > meus locks. quando precisar bloquear o acesso aos dados que estão sendo > atualizados utilizo um lock sobre essa tabela. É uma idéia. > a tb_processamento_tmp continua livre para consultas, inserções,updates para > todas as sessões que não forem pegar dados para processamento. Pois apenas > essas sessões tentarão obter o lock sobre a tabela de controle. > > O que você acha? Acho que você está gerando complexidade desnecessária. Veja sobre Advisory Locks em [1] e as funções que controlam esses locks em [2]. [1] http://www.postgresql.org/docs/9.1/static/explicit-locking.html [2] http://www.postgresql.org/docs/9.1/static/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
