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: