Re: MY PATCH

The regression results are correct. It's just that they're different
than what they used to be because of the SQL3 ONLY incompatibility. I
wasn't sure if people wanted to change the regression tests to give the
old results, or just insert the new results.

Also, I don't get any core dump. Are you sure you did a full clean and
initdb?

I am seeing a backend crash in the inherit regression test:

SELECT * FROM ONLY d;
aa | bb | cc | dd
----------+----+----+----
ddd | | |
dddd | | |
ddddd | | |
dddddd | | |
ddddddd | | |
dddddddd | | |
(6 rows)

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?

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

The regression results are correct. It's just that they're different
than what they used to be because of the SQL3 ONLY incompatibility. I
wasn't sure if people wanted to change the regression tests to give the
old results, or just insert the new results.

Also, I don't get any core dump. Are you sure you did a full clean and
initdb?

OK, I have attached my regression diffs. I fixed a small regression
difference this morning for a patch I applied yesterday.

Certainly, the crash is not expected. Also, the other differences don't
seem reasonable for an inheritance patch. Are all the changes correct,
and the old results wrong? If so, we can update the expected files.

e.g.

SELECT sum(gpa) AS avg_6_8 FROM student;
avg_6_8
---------
! 6.8
(1 row)

	--- 46,52 ----
	  SELECT sum(gpa) AS avg_6_8 FROM student;
	   avg_6_8 
	  ---------
	!     16.6
	  (1 row)  

Oh, I see now:

CREATE TABLE student (
gpa float8
) INHERITS (person);

So it seems some of these new results are caused by the new inherit
code. Good.

Can you confirm the other changes are correct?

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

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.

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@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

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.

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@candle.pha.pa.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@candle.pha.pa.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 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?

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@candle.pha.pa.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@candle.pha.pa.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@bitmead.com
http://www.techphoto.org - Photography News, Stuff that Matters

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@candle.pha.pa.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@candle.pha.pa.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@bitmead.com
http://www.techphoto.org - Photography News, Stuff that Matters

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

I guess it's a real bug then. I wasn't aware of that cassert thing. You
may want to back it out until I have a fix.

We can leave it in for a day or two, unless someone objects. Having it
in allows others to help you debug it.

I guess it's a real bug then. I wasn't aware of that cassert thing. You
may want to back it out until I have a fix.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.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 <pgman@candle.pha.pa.us> writes:

#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

I'll betcha this is the same situation that I guessed at in my crash
report: the executor is probably trying to shut down the same plan node
twice.

BTW, the reason I didn't see this particular crash is that I don't
*have* an 'inherit' regression test:

$ ls pgsql/src/test/regress/*inherit*
pgsql/src/test/regress/*inherit* not found

Did you forget to commit some files, Bruce?

Note to Chris: --enable-cassert is an absolute requirement for
testing backend changes, and personally I like to build with
-DCLOBBER_FREED_MEMORY as well.

regards, tom lane

I'll betcha this is the same situation that I guessed at in my crash
report: the executor is probably trying to shut down the same plan node
twice.

BTW, the reason I didn't see this particular crash is that I don't
*have* an 'inherit' regression test:

$ ls pgsql/src/test/regress/*inherit*
pgsql/src/test/regress/*inherit* not found

Did you forget to commit some files, Bruce?

They came to me in a later e-mail. They are in CVS now.

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

Tom Lane wrote:

Note to Chris: --enable-cassert is an absolute requirement for
testing backend changes, and personally I like to build with
-DCLOBBER_FREED_MEMORY as well.

Is there a configure option for CLOBBER_FREED_MEMORY?

I think you can just manually define it in config.h or in the Makefile.

Tom Lane wrote:

Note to Chris: --enable-cassert is an absolute requirement for
testing backend changes, and personally I like to build with
-DCLOBBER_FREED_MEMORY as well.

Is there a configure option for CLOBBER_FREED_MEMORY?

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

OK, I see at least one of the problems here.

UPDATE/DELETE with an Append plan have never worked --- not in recent
memory anyway --- because execMain's InitPlan() creates a result
RelationInfo that EndPlan() is expecting to close. But if the top plan
node is an Append then nodeAppend.c scribbles on
estate->es_result_relation_info. This leaves the originally created
RelationInfo unreachable ... which is bad enough, since that means a
leaked rel refcount, but there's worse to come. nodeAppend.c creates
its own set of RelationInfo nodes for the relation(s) it will scan.
At query end, it's left estate->es_result_relation_info pointing at a
random one of these. nodeAppend.c closes *and deletes* all its
RelationInfos. Now estate->es_result_relation_info is pointing at a
closed-and-deleted RelationInfo that EndPlan() will then try to close
again. Oops.

I believe the correct fix is
(a) ExecInitAppend() must incorporate the RelationInfo already
created by InitPlan() into its list of RelationInfos, rather
than creating a second RelationInfo (= extra relcache refcount)
for that relation.
(b) ExecEndAppend() must reset estate->es_result_relation_info to
NULL, so it won't be left pointing to a deleted RelationInfo.
(c) EndPlan() must not examine estate->es_result_relation_info until
after it has called the node-type-specific end routine; otherwise
change (b) will not be able to prevent EndPlan() from doing the
wrong thing.

On it now...

regards, tom lane