Em Ter, 2013-05-07 às 10:57 -0300, Flavio Henrique Araque Gurgel escreveu: > Em 07-05-2013 10:49, Dickson S. Guedes escreveu: > > A questão é que se eu faço um SELECT FOR UPDATE no registro X numa > > sessão, você (em qualquer outra sessão) vai conseguir executar um SELECT > > "normal" no mesmo registro X, e pelo que entendi é este impeditivo que o > > Izaque quer. > > Se ele quer impedir um SELECT, como isso não é possível, afinal o > PostgreSQL é evoluído para justamente isso não ocorrer, ele pode de > repente utilizar advisory locks e testar o lock dentro da transação > *antes* de fazer qualquer outra coisa. > > Ideia apenas, divagando... > Mas que terá que haver alteração no código da aplicação, isso temos certeza.
Eu tinha pensado nisto, mas mesmo assim é uma ação explicita por parte de quem vai executar o código, então se vai usar algo explicito que comece pelo FOR SHARE já que os advisory locks tem o mesmo problema que o FOR SHARE caso um simples SELECT não possa ser executado. Entretanto fico divagando se o que ele precisa, num nível mais abstrato, não seriam transações serializadas [1] Talvez RULES, dentro de um outro escopo, também poderiam ser utilizadas, mas como acho que podem acabar sendo o martelo para um parafuso nem vou colocar link de referência. :) Se via SE-Postgres fosse possível fazer restrição de contexto por granularidade de linha talvez seria uma alternativa, mas ainda assim acho que temos um XYProblem aqui já que as soluções apontam para métodos não parcimoniosos. [1] http://www.postgresql.org/docs/current/static/transaction-iso.html#XACT-SERIALIZABLE -- Dickson S. Guedes mail/xmpp: [email protected] - skype: guediz http://guedesoft.net - http://www.postgresql.org.br http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A
signature.asc
Description: This is a digitally signed message part
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
