Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> 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.


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

Sent via pgsql-patches mailing list (
To make changes to your subscription:

Reply via email to