Re: [HACKERS] Current sources? - Mailing list 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@insightdist.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@insightdist.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@insightdist.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@insightdist.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@illustra.com   510.536.1443 (h)  510.628.3783 (w)
           or davidg@dnai.com   510.305.9468 (Bat phone)
--  A child of five could understand this! Fetch me a child of five.