Re: [HACKERS] latest snapshot crashes backend - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] latest snapshot crashes backend
Date
Msg-id 199811042001.PAA14927@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] latest snapshot crashes backend  ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>)
List pgsql-hackers
> > Care to give us a table:
> >  select * from pg_shadow where (usesysid is null and oid is null);
> 
> Sure, that's easy. Just negate your where clause:
> 
> tgl=> select * from pg_shadow
> tgl-> where not (usesysid is null and oid is null);
> pqReadData() -- backend closed the channel unexpectedly.
> 
> If you can reproduce this, will you have a chance to look at it? I don't
> know where the problem is, but suspect that it is farther back than the
> parser transformations. Rewrite system, optimizer, or executor??

Here is the problem:(gdb) print ((Expr *) clause)->oper$1 = (Node *) 0x0

We have dealt with this before in relation to NOT.  The system assumes
NOT is an OP_EXPR oper, while it really isn't.

I fixed another query about a month ago relating to this.  In that case,
flatten_tlistentry() was loosing information about EXPR nodes.

In this case, the code:
       Oid         opno = ((Oper *) ((Expr *) clause)->oper)->opno;

clearly is making an assumption it should not be making.

In this case, clause is:
(gdb) print ((Expr *)clause)[0]$3 = {type = T_Expr, typeOid = 0, opType = NOT_EXPR, oper = 0x0,   args = 0x8307f90}

where opType is not OP_EXPR, but NOT_EXPR.

I am inclined to check for NOT_EXPR, let the selectivity be computed on
the subclause, and negate(NOT) the resulting selectivity.  Not sure on
an exact fix yet, but this is a 6.4.1 issue, anyway.


Problem is in the optimizer:

---------------------------------------------------------------------------


#0  0x80bb1c4 in compute_selec (root=0x82d8590, clauses=0x8307fb0,    or_selectivities=0x0) at clausesel.c:274
#1  0x80bb0cb in compute_clause_selec (root=0x82d8590, clause=0x830ea50,    or_selectivities=0x0) at clausesel.c:182
#2  0x80bfc9c in add_clause_to_rels (root=0x82d8590, clause=0x830ea50)   at initsplan.c:211
#3  0x80bfbea in init_base_rels_qual (root=0x82d8590, clauses=0x830f050)   at initsplan.c:155
#4  0x80c01bb in subplanner (root=0x82d8590, flat_tlist=0x830f170,    qual=0x830f050) at planmain.c:262
#5  0x80c00f8 in query_planner (root=0x82d8590, command_type=1,    tlist=0x83077d0, qual=0x83063d0) at planmain.c:176
#6  0x80c085d in union_planner (parse=0x82d8590) at planner.c:151
#7  0x80c06d5 in planner (parse=0x82d8590) at planner.c:72
#8  0x80f56b4 in pg_parse_and_plan (   query_string=0x80455e4 "select * from pg_shadow where not (usesysid is null and
oidis null);\n", typev=0x0, nargs=0, queryListP=0x8045594, dest=Debug,    aclOverride=0 '\000') at postgres.c:628
 
#9  0x80f57f3 in pg_exec_query_dest (   query_string=0x80455e4 "select * from pg_shadow where not (usesysid is null and
oidis null);\n", dest=Debug, aclOverride=0) at postgres.c:722
 


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


pgsql-hackers by date:

Previous
From: "Jackson, DeJuan"
Date:
Subject: RE: [HACKERS] PL/pgSQL a great procedural language for PostgreSQL
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Warning!!