Re: Delete cascade with three levels bug ?

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

In response to

Responses

Browse pgsql-hackers by date

  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