Re: Delete cascade with three levels bug ? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Delete cascade with three levels bug ?
Date
Msg-id 603c8f070910271000h13888dc8wdeb2e93ad4a02e46@mail.gmail.com
Whole thread Raw
In response to Re: Delete cascade with three levels bug ?  (Euler Taveira de Oliveira <euler@timbira.com>)
Responses Re: Delete cascade with three levels bug ?
List pgsql-hackers
On Tue, Oct 27, 2009 at 10:41 AM, Euler Taveira de Oliveira
<euler@timbira.com> wrote:
> Marcelo Costa escreveu:
>> Hi, hackers
>>
>> I have a problem at PostgreSQL 8.3.5 (Slackware Server and Win 2003
>> Server) SO independent.
>>
>> When run the scripts below I receive the error:
>>
> This is not a bug. There are many ways to shoot yourself in the foot; and it
> is one of them...
>
>> UPDATE pg_trigger SET tgdeferrable = TRUE, tginitdeferred = TRUE;
>>
> This query will defer all of the triggers, including the cascade ones. If you
> compiles with --enable-cassert you will see:
>
> TRAP: FailedAssertion("!(afterTriggers->query_depth >= 0)", Arquivo:
> "/a/pgsql/src/backend/commands/trigger.c", Linha: 3893)
>
> Why don't you use the syntax (DEFERRABLE and INITIALLY DEFERRED)? That will do
> the Right Thing (TM).
>
> BTW, is it worth preventing such a crash putting an elog message in trigger.c?

It doesn't seem right to allow a catalog change that results in an
assertion failure.  Seems like we should either prevent the catalog
change, or have an elog() there rather than Assert().

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Next
From: Josh Berkus
Date:
Subject: Re: Should we warn users about SETs which have no effect?