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

Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]

From: NikhilS <nikkhils(at)gmail(dot)com>
To: "Alex Hunsaker" <badalex(at)gmail(dot)com>
Cc: "Pg Patches" <pgsql-patches(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]
Date: 2008-03-31 08:36:16
Message-ID: d3c4af540803310136k3be3887aq25073ab15ba8dc72@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Hi Alex,

On Sun, Mar 30, 2008 at 7:10 AM, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:

> (trimmed cc's)
>
> Find attached inherited_constraint_v2.patch
>
> Changes since v1:
> -rebased against latest HEAD
> -changed enum { Anum_pg_constraint_... } back into #define
> Anum_pg_constraint_...
> -remove whitespace damage I added
> -fixed regression tests I added to be more robust
> -fixed
>   create table ac (a int constraint check_a check (a <> 0));
>   create table bc (a int constraint check_a check (a <> 0)) inherits (ac);
>   so it properly works (removed crud I put into
> AddRelationRawConstraints and created a proper fix in DefineRelation)
>

I was taking a look at this patch to add the pg_dump related changes. Just
wanted to give you a heads up as this patch crashes if we run "make
installcheck". Seems there is an issue introduced in the CREATE TABLE
REFERENCES code path due to your patch (this is without my pg_dump changes
just to be sure).  Looks like some memory overwrite issue. The trace is as
follows:

Core was generated by `postgres: nikhils regression [local] CREATE
TABLE                     '.
Program terminated with signal 11, Segmentation fault.
#0  0x08378024 in AllocSetCheck (context=0xa060368) at aset.c:1112
1112                            if (dsize > 0 && dsize < chsize &&
*chdata_end != 0x7E)
(gdb) bt
#0  0x08378024 in AllocSetCheck (context=0xa060368) at aset.c:1112
#1  0x0837704f in AllocSetDelete (context=0xa060368) at aset.c:487
#2  0x083783c2 in MemoryContextDelete (context=0xa060368) at mcxt.c:196
#3  0x083797fb in PortalDrop (portal=0xa0845bc, isTopCommit=0 '\0') at
portalmem.c:448
#4  0x08281939 in exec_simple_query (
    query_string=0xa07e564 "CREATE TABLE enumtest_child (parent rainbow
REFERENCES enumtest_parent);") at postgres.c:992
#5  0x082857d4 in PostgresMain (argc=4, argv=0x9ffbe28, username=0x9ffbcc4
"nikhils") at postgres.c:3550
#6  0x0824917b in BackendRun (port=0xa003180) at postmaster.c:3204
#7  0x082486a2 in BackendStartup (port=0xa003180) at postmaster.c:2827
#8  0x08245e9c in ServerLoop () at postmaster.c:1271
#9  0x082457fd in PostmasterMain (argc=3, argv=0x9ff9c60) at postmaster.c
:1019
#10 0x081e1c03 in main (argc=3, argv=0x9ff9c60) at main.c:188


Regards,
Nikhils
-- 
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-03-31 08:40:06
Subject: Re: Commit fest status
Previous:From: Stuart BrooksDate: 2008-03-31 08:03:23
Subject: ANALYZE getting dead tuple count hopelessly wrong

pgsql-patches by date

Next:From: Peter EisentrautDate: 2008-03-31 10:02:47
Subject: Re: [PATCHES] Minimum selectivity estimate for LIKE 'prefix%'
Previous:From: Tom LaneDate: 2008-03-30 19:09:20
Subject: Re: [PATCHES] psql slash# command

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