Обсуждение: BUG #5950: backend terminating after altering table

The following bug has been logged online:

Bug reference:      5950
Logged by:          alex
Email address:      perepelica.alex@gmail.com
PostgreSQL version: 9.0.3
Operating system:   archlinux x86_64
Description:        backend terminating after altering table
Details:

Such steps:
1. create table t (
);
2. alter table t add childs t;
3. alter table t add id serial not null primary key;
This messages from psql:

NOTICE:  ALTER TABLE will create implicit sequence "t_id_seq" for serial
column "t.id"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "t_pkey"
for table "t"
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

backend - terminated

"alex" <perepelica.alex@gmail.com> writes:
> 1. create table t (
> );
> 2. alter table t add childs t;
> 3. alter table t add id serial not null primary key;
> server closed the connection unexpectedly

Hmm.  This seems to be fixed in HEAD:

regression=# create table t (
regression(# );
CREATE TABLE
regression=# alter table t add childs t;
ALTER TABLE
regression=#  alter table t add id serial not null primary key;
NOTICE:  ALTER TABLE will create implicit sequence "t_id_seq" for serial column "t.id"
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "t_pkey" for table "t"
ERROR:  cannot alter table "t" because column "t"."childs" uses its rowtype

Interestingly, 8.2 also says the same --- but 8.3, 8.4, and 9.0 crash.
Looks like we broke the error check somewhere along the way, and whoever
fixed it neglected to back-patch.

            regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

> "alex" <perepelica.alex@gmail.com> writes:
> > 1. create table t (
> > );
> > 2. alter table t add childs t;
> > 3. alter table t add id serial not null primary key;
> > server closed the connection unexpectedly
>
> Hmm.  This seems to be fixed in HEAD:

Not fully. There are also two cases with Segmentation fault
(from sql.ru forum):
1.
create table t ();
alter table t add childs t;
create table selfchield_new (like t);

2.
create table t ();
alter table t add childs t;
create table selfchield_new as select * from t;

I have segmentation fault with current master 7c7fd882.

--
Sergey Burladyan

Sergey Burladyan <eshkinkot@gmail.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> "alex" <perepelica.alex@gmail.com> writes:
>>> 1. create table t (
>>> );
>>> 2. alter table t add childs t;
>>> 3. alter table t add id serial not null primary key;
>>> server closed the connection unexpectedly

>> Hmm.  This seems to be fixed in HEAD:

> Not fully. There are also two cases with Segmentation fault
> (from sql.ru forum):

Yeah, I had already come to the conclusion that it was just luck that
HEAD avoids the specific problem.  See
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01673.php

            regards, tom lane

"alex" <perepelica.alex@gmail.com> writes:
> Such steps:
> 1. create table t (
> );
> 2. alter table t add childs t;
> 3. alter table t add id serial not null primary key;
> server closed the connection unexpectedly

Thanks for the report.  Fixed as per today's discussion (ie, disallow
creating a self-referencing rowtype).

            regards, tom lane