I wrote:
> The crash occurs because we queue a deferred trigger here ...
> when we are not inside any AfterTriggerBeginQuery/AfterTriggerEndQuery
> pair. Normally _SPI_pquery() would take care of that detail, but it's
> been specifically told not to by the RI trigger code (notice the
> fire_trigge
Marcelo Costa writes:
> [ trying to defer RI_FKey_cascade_del trigger crashes the backend ]
I looked at this a bit more and think that there's more to it than pilot
error. The crash occurs because we queue a deferred trigger here:
#0 AfterTriggerSaveEvent (relinfo=0x40181778, event=1, row_trig
Robert Haas writes:
> On Tue, Oct 27, 2009 at 10:41 AM, Euler Taveira de Oliveira
>> 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 th
On Tue, Oct 27, 2009 at 10:41 AM, Euler Taveira de Oliveira
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 m
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 p
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:
---
testes=# DELETE FROM pai WHERE co_pai = 1;
server closed the connect
