Re: Server crash caused by CHECK on child

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Kovacs Baldvin <kb136(at)hszk(dot)bme(dot)hu>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org, Kevin Way <kevin(dot)way(at)overtone(dot)org>
Subject: Re: Server crash caused by CHECK on child
Date: 2001-10-11 20:38:37
Message-ID: 200110112038.f9BKcbD10024@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers pgsql-sql


I can confirm this now works fine in current sources. No crash.

> -- Hi Kevin, and everyone!
> --
> -- I don't think that I only found a minor bug compared to
> -- the other you wrote in your last letter: the backend crash
> -- is caused by the same CHECK constraint in the child table.
> --
> -- However, for you without time to analyzing Kevin's huge
> -- scheme, here is the very simplified, crash-causing script.
> --
> ------------------------------------
>
> drop table child;
> drop table ancestor;
>
> create table ancestor (
> node_id int4,
> a int4
> );
>
> create table child (
> b int4 NOT NULL DEFAULT 0 ,
> c int4 not null default 3,
> CHECK ( child.b = 0 OR child.b = 1 )
> ) inherits (ancestor);
>
> insert into ancestor values (3,4);
> insert into child (node_id, a, b) values (5,6,1);
>
> update ancestor set a=8 where node_id=5;
>
> ---------------------------------
> --
> -- I am hunting it, but I have to learn all what this query-executing
> -- about, so probably it takes uncomparable longer for me than for
> -- a developer.
> --
> -- Regards,
> -- Baldvin
> --
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Orion 2001-10-11 21:14:33 Index Scans Oddness
Previous Message Bruce Momjian 2001-10-11 20:25:27 Re: SQLCODE==-209

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-10-11 20:40:18 Re: [HACKERS] Tupple statistics function
Previous Message Bruce Momjian 2001-10-11 20:37:33 Re: CLUSTER TODO item

Browse pgsql-sql by date

  From Date Subject
Next Message Patrik Kudo 2001-10-12 08:16:33 Re: indexing and LIKE
Previous Message Orion 2001-10-11 20:31:59 count(*) and limit