> Rogério Grando escreveu: > >> Ao executar os scripts a baixo ocorre o segunte erro: >> WARNING: terminating connection because of crash of another server process >> DETAIL: The postmaster has commanded this server process to roll back >> the current transaction and exit, because another server process exited >> abnormally and possibly corrupted shared memory. >> > Isso *não* é um bug. Há várias maneiras de derrubar o postgres; e, essa é mais > uma delas. > OK entendi. >> UPDATE pg_trigger SET tgdeferrable = TRUE, tginitdeferred = TRUE; >> >> > Por que você está fazendo isso? Nem todas os gatilhos são postergáveis (aka > _deferrable_). Assim, você está definindo como postergáveis os gatilhos que > fazem o cascateamento, que por sua vez, está levando a queda do postgres. > Talvez seja viável a prevenção de tal cenário mas ... > > Sugiro que utilize a sintaxe (DEFERRABLE and INITIALLY DEFERRED) para definir > se os gatilhos são postergáveis ou não; só mexa no catálogo quando tiver > certeza que o que você está fazendo é seguro. > Faço isso porque migramos nossa base de 7.4 para 8.3, e deparamos com essa situação onde o delete e insert em uma transação deve seguir a ordem correta sendo na inserção de pai para filho e na exclusão de filho para o pai. O custo para fazer assa alteração na aplicação é muito grande então resolvemos Postergar a validação de todas as triggers que no nosso caso são mais de 2 mil. Não vejo outra forma de resolver essa situação, teremos que mexer na aplicação para ordenar os deletes e inserts. Obrigado Euler, vou analisar melhor a dica da sintaxe (DEFERRABLE and INITIALLY DEFERRED) vou fazer mais alguns testes e posto aqui caso aja alguma mudança. Agradeço a todos pela ajuda, e parabenizo a todos pela PgCon que estava muito boa, deixei até um trocado lá.
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
