Re: Server crash caused by CHECK on child

-- 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
--

> -- 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.

Oooh, my bad. I should run your scripts before assuming I know how
they fail.

> -- However, for you without time to analyzing Kevin's huge
> -- scheme, here is the very simplified, crash-causing script.

Thank you so much for finding this simplified method of crashing
Postgres. Hopefully somebody can find a fix now.

> -- 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.

That's my problem as well, though your example is vastly easier to
trace than mine.

-Kevin Way

What version are you trying this script on? I'm not
seeing a crash on my 7.2 devel system (and the update occurs).

On Mon, 24 Sep 2001, Kovacs Baldvin wrote:

> -- 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;

> What version are you trying this script on? I'm not
> seeing a crash on my 7.2 devel system (and the update occurs).

7.1.3. I'll sup a copy of the 7.2 sources and see if that fixes the test
case, and my actual bug.

-Kevin Way

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