From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
Cc: | Marcelo Costa <marcelojscosta(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Delete cascade with three levels bug ? |
Date: | 2009-10-27 17:00:49 |
Message-ID: | 603c8f070910271000h13888dc8wdeb2e93ad4a02e46@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 27, 2009 at 10:41 AM, Euler Taveira de Oliveira
<euler(at)timbira(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-10-27 17:01:51 | Re: Should we warn users about SETs which have no effect? |
Previous Message | Robert Haas | 2009-10-27 16:59:37 | Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order |