Re: [HACKERS] latest snapshot crashes backend

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

In response to

Browse pgsql-hackers by date

  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