Subject: Re: Bug with array-retrieve in time-clause queries

From: [email-masked] (Wolf-D. Ihlenfeldt)
Date: Thu, 15 Jul 93 21:57:29 -0700

This is a followup to my last post.
I am running pg4.1 on SparcII with SunOS 4.1.2

After MUCH experimenting, I am able to present some nice 
reproducable small examples of this bug. 

Go 
* create z(x=int4) archive=light\g

Query sent to backend is "create z(x=int4) archive=light"
CREATE
* addattr (a=int4[],b=int4[],y=int4,s=text[],t=text[]) to z\g

Query sent to backend is "addattr (a=int4[],b=int4[],y=int4,s=text[],t=text[]) to z"
ADD
Go 
* append z (a="{1,2,3}",b="{4,5,6}",x=1,y=2,s="{"a","b"}",t="{"d","e"}")\g

Query sent to backend is "append z (a="{1,2,3}",b="{4,5,6}",x=1,y=2,s="{"a","b"}",t="{"d","e"}")"
APPEND 197997
Go 

OK, we set up a small example database. Now some queries which work
like expected:

Query sent to backend is "retrieve (Q.a,Q.x) from Q in z["now"] where Q.oid = "197997""
-----------------------------
| a           | x           |
-----------------------------
| {1,2,3}     | 1           |
-----------------------------

(Mixture int4[], int: perfect)

* retrieve (Q.a,Q.s)  from Q in z["now"] where Q.oid = "197997"\g

Query sent to backend is "retrieve (Q.a,Q.s)  from Q in z["now"] where Q.oid = "197997""
-----------------------------
| a           | s           |
-----------------------------
| {1,2,3}     | {"a","b"}   |
-----------------------------

(Mixture int4[], text[]: perfect)

* retrieve (Q.a,Q.y,Q.s)  from Q in z["now"] where Q.oid = "197997"\g

Query sent to backend is "retrieve (Q.a,Q.y,Q.s)  from Q in z["now"] where Q.oid = "197997""
-------------------------------------------
| a           | y           | s           |
-------------------------------------------
| {1,2,3}     | 2           | {"a","b"}   |
-------------------------------------------

(All three: no problem)

* retrieve (Q.a,Q.a)  from Q in z["now"] where Q.oid = "197997"\g

Query sent to backend is "retrieve (Q.a,Q.a)  from Q in z["now"] where Q.oid = "197997""
-----------------------------
| a           | a           |
-----------------------------
| {1,2,3}     | {1,2,3}     |
-----------------------------

(Duplicate retrieval: no problem)

* retrieve (Q.a,Q.b)  from Q in z["now"] where Q.oid = "197997"\g

Query sent to backend is "retrieve (Q.a,Q.b)  from Q in z["now"] where Q.oid = "197997""
Error: No response from the backend, exiting...

Here we are again. Same type of array and the core dumps.

THINGS WHICH WORK:

- untimed query

Go 
* retrieve  (Q.a,Q.b)  from Q in z where Q.oid = "197997"\g

Query sent to backend is "retrieve  (Q.a,Q.b)  from Q in z where Q.oid = "197997""
-----------------------------
| a           | b           |
-----------------------------
| {1,2,3}     | {4,5,6}     |
-----------------------------

- Direct creation of the table, i.e. no addattr-command, but
  all in the 'create' statement. Unformtunately, in my app
  I do not know the fields beforehand, or only a small fraction
  of them, so I cannot avoid using addattr. If the table is created
  directly, all queries work.
  I think the culprit is 'addattr' .. something gets messed up in a
  probably very subtle way.

THINGS WHICH DO NOT WORK:

- I was wrong that this is an array-related bug (in the app where
this bug showed up first, all the fields in question were arrays).
The core is dumped with plain int4's as well, if time-clause query
and creation by addattr come together. But all this happens only,
if more then one field of the same type, which was added by addattr,
is in the requested set. Fields which were set up with 'create' can
be freely combined with up to 1 field of every type which was 
added later. But only 1 of every type. Extremely strange, and
extremely inconvenient.

The crash location is always the same:

get_expr() at 0x65edc
flatten_tlistentry() at 0x67848
flatten_tlist_vars() at 0x677bc
query_planner() at 0x5bbe8
init_query_planner() at 0x5ca64
planner() at 0x5c874
plan_union_query() at 0x60b9c
plan_union_queries() at 0x609e4
planner() at 0x5c7c8
pg_plan() at 0x89e38
pg_eval_dest() at 0x89f10
pg_eval() at 0x89ee4
PostgresMain() at 0x8b478
main() at 0x2b78c

Postgres Team, please help! help!

WDI