Skip site navigation (1) Skip section navigation (2)

Re: BUG #5856: pg_attribute.attinhcount is not correct.

From: Noah Misch <noah(at)leadboat(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Naoya Anzai <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #5856: pg_attribute.attinhcount is not correct.
Date: 2011-03-31 10:06:49
Message-ID: 20110331100649.GA7286@tornado.gateway.2wire.net (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
[moving to pgsql-hackers]

On Thu, Feb 03, 2011 at 11:24:42AM -0500, Robert Haas wrote:
> On Mon, Jan 31, 2011 at 6:42 AM, Naoya Anzai
> <anzai-naoya(at)mxu(dot)nes(dot)nec(dot)co(dot)jp> wrote:
> > In PostgreSQL8.4.5, I found that the catalog pg_attribute.attinhcount is not
> > correct.
> >
> > I executed the following queries.
> >
> > --------------------------------------------------------------------------
> > create table "3_grandchild"();
> > create table "2_child"();
> > create table "1_parent"();
> >
> > alter table "3_grandchild" inherit "2_child";
> > alter table "2_child" inherit "1_parent";
> >
> > alter table "3_grandchild" add column c1 text;
> > alter table "2_child" add column c1 text;
> > alter table "1_parent" add column c1 text;
> >
> > select c.relname,a.attname,a.attinhcount from pg_attribute a,pg_class c
> > where a.attrelid=c.oid
> > and relname in ('1_parent','2_child','3_grandchild')
> > and attname not in('xmax','xmin','cmin','cmax','tableoid','ctid')
> > order by relname;
> >
> > ? ?relname ? ?| attname | attinhcount
> > ?--------------+---------+-------------
> > ?1_parent ? ? | c1 ? ? ?| ? ? ? ? ? 0
> > ?2_child ? ? ?| c1 ? ? ?| ? ? ? ? ? 1
> > ?3_grandchild | c1 ? ? ?| ? ? ? ? ? 2
> > ?(3 rows)
> > --------------------------------------------------------------------------
> >
> > "3_grandchild"'s attinhcount should be 1.
> 
> I think this is a manifestation the same problem mentioned here:
> 
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=31b6fc06d83c6de3644c8f2921eb7de0eb92fac3
> 
> I believe this requires some refactoring to fix.  It would be good to do that.

The best way I can see is to make ATExecAddColumn more like ATExecDropColumn,
ATAddCheckConstraint, and ATExecDropConstraint.  Namely, recurse at Exec-time
rather than Prep-time, and cease recursing when we satisfy the ADD COLUMN with a
merge.  Did you have something else in mind?

Incidentally, when we satisfy an ADD COLUMN with a merge, we do not check or
update attnotnull:

create table parent();
create table child(c1 text) inherits (parent);
alter table parent add column c1 text not null;
\d child

We could either update attnotnull (and schedule a phase-3 scan of the table) or
throw an error.  For ALTER TABLE ... INHERIT, we throw the error.  For CREATE
TABLE ... INHERITS, we add the NOT NULL (and no scan is needed).  I'd weakly
lean toward throwing the error.  Opinions?

nm

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-03-31 10:31:24
Subject: Re: crash-safe visibility map, take four
Previous:From: Heikki LinnakangasDate: 2011-03-31 09:43:26
Subject: Re: Re: [COMMITTERS] pgsql: Fix plpgsql to release SPI plans when a function or DO block is

pgsql-bugs by date

Next:From: Jon NelsonDate: 2011-03-31 11:41:32
Subject: Re: backend for database 'A' crashes/is killed -> corrupt index in database 'B'
Previous:From: Heikki LinnakangasDate: 2011-03-31 07:58:55
Subject: Re: backend for database 'A' crashes/is killed -> corrupt index in database 'B'

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group