Return-Path: pg_adm@postgres.berkeley.edu Received: by postgres.Berkeley.EDU (5.61/1.29) id AA01202; Thu, 15 Jul 93 21:57:29 -0700 Date: Thu, 15 Jul 93 21:57:29 -0700 Message-Id: <9307160457.AA01202@postgres.Berkeley.EDU> From: wolf@molout.tutkie.tut.ac.jp (Wolf-D. Ihlenfeldt) Subject: Re: Bug with array-retrieve in time-clause queries To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu 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