Re: Re: [CORE] Re: MY PATCH

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Chris Bitmead <chris(at)bitmead(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-core(at)postgreSQL(dot)org, "pgsql-patches(at)postgresql(dot)org" <pgsql-patches(at)postgreSQL(dot)org>
Subject: Re: Re: [CORE] Re: MY PATCH
Date: 2000-06-09 12:59:53
Message-ID: 200006091259.IAA19169@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

> Bruce Momjian wrote:
>
> > My guess is that you are closing something you are not opening. I know,
> > run configure with --enable-cassert, and you will see the crash too.
>
> The only place I'm doing that is inside setRelhassubclassInRelation in
> commands/creatinh.c. Is the heap_close in there appropriate?

Looks fine. It seems the executor code is closing a relation it never
opened.

From my backtrace, I see it as relation d. My guess is that your
inheritance scanning is opening/closing the wrong relations sometimes.

(gdb) frame 7
#7 0x8072803 in heap_close (relation=0x8246270, lockmode=0) at heapam.c:620
620 RelationClose(relation);
(gdb) print relation[0]
$1 = {rd_fd = 33, rd_nblocks = 1, rd_refcnt = 0, rd_myxactonly = 0 '\000',
rd_isnailed = 0 '\000', rd_isnoname = 0 '\000', rd_unlinked = 0 '\000',
rd_am = 0x0, rd_rel = 0x8246f50, rd_id = 390177, rd_lockInfo = {lockRelId = {
relId = 390177, dbId = 269920}}, rd_att = 0x8246fd8, rd_rules = 0x0,
rd_istrat = 0x0, rd_support = 0x0, trigdesc = 0x0}
(gdb) print relation[0].rd_rel
$2 = (FormData_pg_class *) 0x8246f50
(gdb) print relation[0].rd_rel[0]
$3 = {relname = {data = "d", '\000' <repeats 30 times>, alignmentDummy = 100},
reltype = 0, relowner = 139, relam = 0, relpages = 1, reltuples = 6,
rellongrelid = 0, relhasindex = 0 '\000', relisshared = 0 '\000',
relkind = 114 'r', relnatts = 4, relchecks = 0, reltriggers = 0,
relukeys = 0, relfkeys = 0, relrefs = 0, relhaspkey = 0 '\000',
relhasrules = 0 '\000', relhassubclass = 0 '\000', relacl = {0}}

>
>
> >
> > > >
> > > > > UPDATE a SET aa='zzzz' WHERE aa='aaaa';
> > > > > pqReadData() -- backend closed the channel unexpectedly.
> > > > > This probably means the backend terminated abnormally
> > > > > before or while processing the request.
> > > > > connection to server was lost
> > > > >
> > > > > Should I send you a backtrace?
> > > >
> > > > I guess so. I'm definitely not seeing it.
> > > >
> > >
> > > Sure:
> > >
> > > #0 0x281e9d65 in kill ()
> > > #1 0x28235a5d in abort ()
> > > #2 0x81492d8 in ExcAbort (excP=0x819f8fc, detail=0, data=0x0,
> > > message=0x8195bd6 "!((relation)->rd_refcnt > 0)") at excabort.c:27
> > > #3 0x8149227 in ExcUnCaught (excP=0x819f8fc, detail=0, data=0x0,
> > > message=0x8195bd6 "!((relation)->rd_refcnt > 0)") at exc.c:170
> > > #4 0x814927f in ExcRaise (excP=0x819f8fc, detail=0, data=0x0,
> > > message=0x8195bd6 "!((relation)->rd_refcnt > 0)") at exc.c:187
> > > #5 0x81487bf in ExceptionalCondition (
> > > conditionName=0x8195bd6 "!((relation)->rd_refcnt > 0)",
> > > exceptionP=0x819f8fc, detail=0x0, fileName=0x8195a21 "relcache.c",
> > > lineNumber=1337) at assert.c:73
> > > #6 0x81457e2 in RelationClose (relation=0x8243268) at relcache.c:1337
> > > #7 0x8072803 in heap_close (relation=0x8243268, lockmode=0) at heapam.c:620
> > > #8 0x80ae9e2 in EndPlan (plan=0x824bf90, estate=0x824cc18) at execMain.c:958
> > > #9 0x80ae2b0 in ExecutorEnd (queryDesc=0x824cc00, estate=0x824cc18)
> > > at execMain.c:358
> > > #10 0x810db6c in ProcessQueryDesc (queryDesc=0x824cc00, limoffset=0x0,
> > > limcount=0x0) at pquery.c:336
> > > #11 0x810dbce in ProcessQuery (parsetree=0x8234288, plan=0x824bf90,
> > > dest=Remote) at pquery.c:369
> > > #12 0x810c5df in pg_exec_query_dest (
> > > query_string=0x81cd368 "UPDATE a SET aa='zzzz' WHERE aa='aaaa';",
> > > dest=Remote, aclOverride=0) at postgres.c:642
> > > #13 0x810c4c4 in pg_exec_query (
> > > query_string=0x81cd368 "UPDATE a SET aa='zzzz' WHERE aa='aaaa';")
> > > at postgres.c:539
> > > #14 0x810d56d in PostgresMain (argc=6, argv=0x804725c, real_argc=5,
> > > real_argv=0x8047998) at postgres.c:1528
> > > #15 0x80f20cc in DoBackend (port=0x81d7000) at postmaster.c:1951
> > > #16 0x80f1c52 in BackendStartup (port=0x81d7000) at postmaster.c:1738
> > > #17 0x80f0e86 in ServerLoop () at postmaster.c:983
> > > #18 0x80f090c in PostmasterMain (argc=5, argv=0x8047998) at postmaster.c:676
> > > #19 0x80c0ae7 in main (argc=5, argv=0x8047998) at main.c:93
> > > #20 0x806373c in __start ()
> > >
> > > I can let you login in and poke around.
> > > --
> > > Bruce Momjian | http://www.op.net/~candle
> > > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> > > + If your life is a hard drive, | 830 Blythe Avenue
> > > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> > >
> >
> > --
> > Bruce Momjian | http://www.op.net/~candle
> > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> > + If your life is a hard drive, | 830 Blythe Avenue
> > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
> --
> Chris Bitmead
> mailto:chris(at)bitmead(dot)com
> http://www.techphoto.org - Photography News, Stuff that Matters
>

--
Bruce Momjian | http://www.op.net/~candle
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message David Reid 2000-06-09 13:05:23 BeOS take 2
Previous Message Chris Bitmead 2000-06-09 12:45:22 Re: Re: [CORE] Re: MY PATCH