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: