Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
От | Tom Lane |
---|---|
Тема | Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha) |
Дата | |
Msg-id | 4300.977847974@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 7.1 on DEC/Alpha (Brent Verner <brent@rcfile.org>) |
Список | pgsql-hackers |
Brent Verner <brent@rcfile.org> writes: > more observations WRT sql that blows up postgres on Alpha. > works: > SELECT p.hobbies.equipment.name, p.hobbies.name, p.name > FROM ONLY person p; > breaks: > SELECT p.hobbies.equipment.name, p.hobbies.name, p.name > FROM person p; > SELECT p.hobbies.equipment.name, p.hobbies.name, p.name > FROM person* p; OK, I see the problem. The breakage actually is present in 7.0.* and prior versions as well, it just doesn't happen to be exposed by the regress tests --- until now. The trouble is the way that entire-tuple function arguments are handled. Tuple types are declared in pg_type as being the same size as Oid, ie, 4 bytes. This reflects situations where a tuple value is represented by an Oid reference to a row in a table. (I am not sure whether there is any code left that depends on that ... in any case I'm nervous about changing it during beta.) But the expression evaluator's implementation of a tuple argument is that the Datum value contains a pointer to a TupleTableSlot. This works fine as long as the Datum is just passed around as a Datum, but if anyone tries to form a tuple containing that Datum, only 4 bytes get stored into the tuple. Result: failure on machines where pointers are wider than 4 bytes. The reason this shows up in this particular regression test now, and not before, is that 7.1 does the function evaluations at the top of the Append plan that implements inheritance union, whereas 7.0 did it at the bottom. That means that in 7.1, the TupleTableSlot Datum gets inserted into a tuple that becomes part of the Append output before it gets to the function execution. 7.0 would still show the bug under the right circumstances --- a join would do it, for example. I think that there may still be cases where an Oid is the correct representation of a tuple type; anyway I'm afraid to foreclose that possibility. What I'm thinking about doing is setting typmod of an entire-tuple function argument to sizeof(Pointer), rather than the default -1, to indicate that a pointer representation is being used. Comments, hackers? regards, tom lane
В списке pgsql-hackers по дате отправления: