From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | lockhart(at)alumni(dot)caltech(dot)edu (Thomas G(dot) Lockhart) |
Cc: | olly(at)lfix(dot)co(dot)uk, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] latest snapshot crashes backend |
Date: | 1998-11-04 20:01:40 |
Message-ID: | 199811042001.PAA14927@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 oid is 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 oid is null);\n", dest=Debug, aclOverride=0) at postgres.c:722
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1998-11-04 21:19:15 | Re: [HACKERS] Warning!! |
Previous Message | Jackson, DeJuan | 1998-11-04 19:52:39 | RE: [HACKERS] PL/pgSQL a great procedural language for PostgreSQL |