Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane wrote:
>>> I still haven't seen the actual bug description come by here, and the
>>> pgsql-bugs archive hasn't got it either.
>
>> (apparently some mails on that thread are missing ...)
>
> That's what I meant. Heikki is quoting himself from a message that
> hasn't appeared anywhere public, and he must have had at least one
> message from the OP that hasn't appeared either. So the rest of us
> are still mostly in the dark about the problem.
Hmm, strange. Looks like my mail client decided to sent that mail to
pgsql-bugs-owner@ instead of pgsql-bugs@ for some reasone. Here's the
missing mail:
Ceschia, Marcello wrote:
> In query "query_not_working" all values from column "136_119" has the
value of the first column.
>
> Using the splitted query ("working_version") it works.
>
> I hope this data will help to find the bug.
Thanks.
Oh, the query actually gives an assertion failure on an
assertion-enabled build, so this is clearly a bug:
TRAP: FailedAssertion("!(attnum > 0 && attnum <=
list_length(rte->joinaliasvars))", File: "parse_relation.c", Line: 1697)
gdb tells that attnum is -31393 at that point. That's because
get_rte_attribute_type() takes an AttrNumber, which is int16, and
make_var() is trying to pass 34143, so it overflows.
It seems we should extend AttrNumber to int32; we don't use AttrNumber
in any of the on-disk structs. Though you still couldn't have more than
MaxHeapAttributeNumber (1600) attributes in a table or
MaxTupleAttributeNumber (1664) in a result set or intermediate tuples,
like the output of a sort node, at least you could join ridiculously
wide tables like that as long as you project out enough columns.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com