Thread: Server crash caused by CHECK on child

Server crash caused by CHECK on child

From
Kovacs Baldvin
Date:
-- 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
-- 




Re: Server crash caused by CHECK on child

From
Kevin Way
Date:
> -- 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



Re: [HACKERS] Server crash caused by CHECK on child

From
Stephan Szabo
Date:
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;



Re: Server crash caused by CHECK on child

From
Bruce Momjian
Date:
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@postgresql.org so that your
> message can get through to the mailing list cleanly
> 

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