Re: [HACKERS] Current sources?

From: dg(at)illustra(dot)com (David Gould)
To: tih+mail(at)Hamartun(dot)Priv(dot)NO (Tom Ivar Helbekkmo)
Cc: scrappy(at)hub(dot)org, pgsql-hackers(at)postgreSQL(dot)org, t-ishii(at)sra(dot)co(dot)jp, daveh(at)insightdist(dot)com
Subject: Re: [HACKERS] Current sources?
Date: 1998-05-25 19:23:46
Message-ID: 9805251923.AA15589@hawk.illustra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

tih wrote:
>
> > I'm starting to look forward to when the CVS source tree gets into a
> > buildable state again! This could be a comfortable way of keeping
> > up to date with the current sources. Here's hoping you find a good
> > solution to the s_lock.h misunderstandings soon... :-)
...
> On the weird side, after I updated to the current sources, the backend
> dies on me whenever I try to delete a database, whether from psql with
> 'drop database test' or from the command line with 'destroydb test'.
>
> -tih

Ok, I think I have found the source of the dropconns on "delete" querys
that are causing the current problem. The change listed below sets
tupType to the junkFilter (whatever that is) jf_cleanTupType unconditionally.
This makes a SEGV later as the tupType ends up NULL.

Here is what CVS says:
---------------
revision 1.46
date: 1998/05/21 03:53:50; author: scrappy; state: Exp; lines: +6 -4

From: David Hartwig <daveh(at)insightdist(dot)com>

Here is a patch to remove the requirement that ORDER/GROUP BY clause
identifiers be included in the target list.
--------------

I do not believe that this could ever have passed regression. Do we have
the whole patch to back out, or do we need to just "fix what we have now"?

Also, perhaps we need to be more selective about checkins?

Here is the source containing the problem:

src/backend/executor/execMain.c in InitPlan() at about line 515
/* ----------------
* now that we have the target list, initialize the junk filter
* if this is a REPLACE or a DELETE query.
* We also init the junk filter if this is an append query
* (there might be some rule lock info there...)
* NOTE: in the future we might want to initialize the junk
* filter for all queries.
* ----------------
* SELECT added by daveh(at)insightdist(dot)com 5/20/98 to allow
* ORDER/GROUP BY have an identifier missing from the target.
*/
if (operation == CMD_UPDATE || operation == CMD_DELETE ||
operation == CMD_INSERT || operation == CMD_SELECT)
{
JunkFilter *j = (JunkFilter *) ExecInitJunkFilter(targetList);
estate->es_junkFilter = j;
>>>> tupType = j->jf_cleanTupType; /* Added by daveh(at)insightdist(dot)com 5/20/98 */
}
else
estate->es_junkFilter = NULL;

Here is my debug transcript for "drop database regression"

(gdb) where
#0 InitPlan (operation=CMD_DELETE, parseTree=0x81b68f8, plan=0x81ba468,
estate=0x81ba668) at execMain.c:527
#1 0x8098017 in ExecutorStart (queryDesc=0x81ba640, estate=0x81ba668)
at execMain.c:128
#2 0x80e24d9 in ProcessQueryDesc (queryDesc=0x81ba640) at pquery.c:285
#3 0x80e258e in ProcessQuery (parsetree=0x81b68f8, plan=0x81ba468, argv=0x0,
typev=0x0, nargs=0, dest=Remote) at pquery.c:378
#4 0x80e13b0 in pg_exec_query_dest (
query_string=0xbfffd5f8 "delete from pg_database where pg_database.oid = '18080'::oid", argv=0x0, typev=0x0, nargs=0, dest=Remote) at postgres.c:702
#5 0x80e12b2 in pg_exec_query (
query_string=0xbfffd5f8 "delete from pg_database where pg_database.oid = '18080'::oid", argv=0x0, typev=0x0, nargs=0) at postgres.c:601
#6 0x8096596 in destroydb (dbname=0x81b2558 "regression") at dbcommands.c:136
#7 0x80e304c in ProcessUtility (parsetree=0x81b2578, dest=Remote)
at utility.c:570
#8 0x80e1350 in pg_exec_query_dest (
query_string=0xbfffd928 "drop database regression;", argv=0x0, typev=0x0,
nargs=0, dest=Remote) at postgres.c:656
#9 0x80e12b2 in pg_exec_query (
query_string=0xbfffd928 "drop database regression;", argv=0x0, typev=0x0,
nargs=0) at postgres.c:601
#10 0x80e2001 in PostgresMain (argc=9, argv=0xbffff960) at postgres.c:1417
#11 0x80a7707 in main (argc=9, argv=0xbffff960) at main.c:105
530 JunkFilter *j = (JunkFilter *) ExecInitJunkFilter(targetList);
531 estate->es_junkFilter = j;
(gdb) p j
$7 = (JunkFilter *) 0x81bb2c8
(gdb) p *j
$8 = {type = T_JunkFilter, jf_targetList = 0x81ba600, jf_length = 1,
jf_tupType = 0x81bb238, jf_cleanTargetList = 0x0, jf_cleanLength = 0,
jf_cleanTupType = 0x0, jf_cleanMap = 0x0}
(gdb) n
533 tupType = j->jf_cleanTupType; /* Added by daveh(at)insightdist(dot)com 5/20/98 */
(gdb) p tupType
$9 = (struct tupleDesc *) 0x81baf18
(gdb) n
534 }
(gdb) p tupType
$10 = (struct tupleDesc *) 0x0
(gdb) n
542 intoRelationDesc = (Relation) NULL;
(gdb) n
544 if (operation == CMD_SELECT)
(gdb) n
588 estate->es_into_relation_descriptor = intoRelationDesc;
(gdb) n
600 return tupType;

Returns NULL to ExecutorStart who then pukes.

-dg

David Gould dg(at)illustra(dot)com 510.536.1443 (h) 510.628.3783 (w)
or davidg(at)dnai(dot)com 510.305.9468 (Bat phone)
-- A child of five could understand this! Fetch me a child of five.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryan Kirkpatrick 1998-05-25 21:37:09 Linux/Alpha.... Progress...
Previous Message Tom Lane 1998-05-25 16:14:28 Re: [HACKERS] Query cancel and OOB data