Matheus, não tem erro na lógica das funções. Deixa eu dar maiores detalhes da operação.
oracle.table1 -> AppSincronizador -> postgresql.table1 -> Trigger (upd,ins,del) -> postgresql.table2 Nesse fluxo, a trigger está instalado na "postgresql.table1" onde eu controle UPD,INS,DEL em uma única trigger e decido via TG_OP o que vai ser executado. então, se for UPDATE faço, DELETE seguido de INSERT para a tabela " postgresql.table2" então, se for INSERT faço, INSERT para a tabela "postgresql.table2" então, se for DELETE faço, DELETE para a tabela "postgresql.table2" A tabela "postgresql.table1" é identica a tabela "postgresql.table2" Perguntas: 1. O fato de estar fazendo tomadas de decisão dentro da funtion trigger pode ser que por conta do enfileiramento de operações, algumas se percam ? 2. Usar uma única trigger controlando os eventos por tomada de decisão dentro da plpgsql ou ter 3 triggers, uma para cada evento ? O que é mais performático ? Em 26 de fevereiro de 2015 07:11, Matheus de Oliveira < [email protected]> escreveu: > > 2015-02-25 22:43 GMT-03:00 Emanuel Araújo <[email protected]>: > >> oracle.table1 -> AppSincronizador -> postgresql.table1 -> Trigger >> (upd,ins,del) -> postgresql.table2 >> >> Estou tendo situações onde o volume de dados é grande que as mudanças que >> deveria estar na tabela final não são encontradas, ficando as tabelas no >> postgresql desincronizadas. Bom, a aplicação faz uma única transação e faz >> commits a cada 1000 registros. >> >> É como se as triggers desativassem, pois quando faço manualmente a >> operação é realizada. Existe algum BUG ou situação onde o postgresql >> desative essas triggers ? >> >> >> Versão So: CentOS 6.5 >> Postgresql 9.3.5 >> Oracle: 11G >> >> > Sinceramente não creio ter algum bug que cause isso, deve ser um erro na > lógica de suas funções. > > > >> Encontrei esse POST e queria esclarescimentos principalmente sobre o >> trecho abaixo: >> AFTER triggers are more expensive than BEFORE triggers because they must >> be queued up until the statement finishes doing its work, then executed. >> They aren't spilled to disk if the queue gets big (at least in 9.4 and >> below, may change in future) so huge AFTER trigger queues can cause >> available memory to overrun, resulting in the statement aborting. >> >> Link: >> http://dba.stackexchange.com/questions/88761/scaling-postgresql-triggers >> >> PS. No momento não estou interessado na performance, pois isso cuido >> posteriormente, mas sim na questão de que existem operações aleatórias que >> não concluem para a tabela final. >> > > Não segui o link, mas o que você passou parece sim plausível, mas afetaria > apenas a performance, e se realmente ocorresse falha, a sua transação > inteira é abortada, não só a trigger (a não ser que esteja tratando > exceções nessas funções de forma indevida). > > Atenciosamente, > -- > Matheus de Oliveira > Analista de Banco de Dados > Dextra Sistemas - MPS.Br nível F! > www.dextra.com.br/postgres > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- *Atenciosamente,Emanuel Araújo* *Linux Certified, DBA PostgreSQL*
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
