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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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