Skip site navigation (1) Skip section navigation (2)

Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Brent Verner <brent(at)rcfile(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
Date: 2000-12-26 16:26:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Brent Verner <brent(at)rcfile(dot)org> writes:
> more observations WRT sql that blows up postgres on Alpha.
> works:
>   SELECT,, 
>     FROM ONLY person p;
> breaks:
>   SELECT,, 
>     FROM person p;
>   SELECT,, 
>     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

In response to


pgsql-hackers by date

Next:From: jmoschetDate: 2000-12-26 17:24:08
Subject: Permissions on Stored Procedures
Previous:From: AbeDate: 2000-12-26 12:14:02
Subject: Re: COUNT(Distinct city) HELP!!!

pgsql-patches by date

Next:From: Tom LaneDate: 2000-12-26 19:41:33
Subject: Re: Tuple-valued datums on Alpha (was Re: 7.1 on DEC/Alpha)
Previous:From: Brent VernerDate: 2000-12-26 02:01:06
Subject: Re: 7.1 on DEC/Alpha

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group