Subject: port-alpha/20904: Postgresql-7.4-snapshot, 7.3.2 Fails on NetBSD-1.6 / Alpha
To: None <gnats-bugs@gnats.netbsd.org>
From: None <tom@minnesota.com>
List: netbsd-bugs
Date: 03/27/2003 10:27:39
>Number:         20904
>Category:       port-alpha
>Synopsis:       ! ERROR:  datumGetSize: Invalid typLen 0
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-alpha-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 27 02:28:01 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Thomas T. Thai
>Release:        NetBSD 1.6
>Organization:

--
Thomas T. Thai
Minnesota.com, Inc.
>Environment:
System: NetBSD ns01 1.6 NetBSD 1.6 (ns01-1.6) #1: Mon Nov 25 17:03:01 CST 2002 root@ns01:/usr/src/1.6/sys/arch/alpha/compile/ns01-1.6 alpha
Architecture: alpha
Machine: alpha
>Description:
For Postgresql-7.3.2 and 7.4-snapshot, I get one regression failure on
the Alpha running NetBSD-1.6. This bug only appears on the Alpha and
not i386.

Included inline is the regression test failure and another test case
where this bug shows up.

=======================================================
*** ./expected/opr_sanity.out   Tue Jan 28 16:13:41 2003
--- ./results/opr_sanity.out    Thu Mar 27 03:56:43 2003
***************
*** 46,55 ****
      p1.proname = p2.proname AND
      p1.pronargs = p2.pronargs AND
      p1.proargtypes = p2.proargtypes;
!  oid | proname | oid | proname
! -----+---------+-----+---------
! (0 rows)
!
  -- Considering only built-in procs (prolang = 12), look for multiple
uses
  -- of the same internal function (ie, matching prosrc fields).  It's
OK to
  -- have several entries with different pronames for the same internal
function,
--- 46,52 ----
      p1.proname = p2.proname AND
      p1.pronargs = p2.pronargs AND
      p1.proargtypes = p2.proargtypes;
! ERROR:  datumGetSize: Invalid typLen 0
  -- Considering only built-in procs (prolang = 12), look for multiple
uses
  -- of the same internal function (ie, matching prosrc fields).  It's
OK to
  -- have several entries with different pronames for the same internal
function,
***************
*** 276,285 ****
      p1.oprkind = p2.oprkind AND
      p1.oprleft = p2.oprleft AND
      p1.oprright = p2.oprright;
!  oid | oprcode | oid | oprcode
! -----+---------+-----+---------
! (0 rows)
!
  -- Look for commutative operators that don't commute.
  -- DEFINITIONAL NOTE: If A.oprcom = B, then x A y has the same result
as y B x.
  -- We expect that B will always say that B.oprcom = A as well; that's
not
--- 273,279 ----
      p1.oprkind = p2.oprkind AND
      p1.oprleft = p2.oprleft AND
      p1.oprright = p2.oprright;
! ERROR:  datumGetSize: Invalid typLen 0
  -- Look for commutative operators that don't commute.
  -- DEFINITIONAL NOTE: If A.oprcom = B, then x A y has the same result
as y B x.
  -- We expect that B will always say that B.oprcom = A as well; that's
not

================================================================

System: NetBSD / Alpha 1.6 (64 bit)
Postgresql 7.3.2

Bug: after vacuum analyze, I'm unable to do a simple select. Instead
I'm getting this error:

  ERROR:  datumGetSize: Invalid typLen 0

Many thanks to Teodor Sigaev for helping verify this bug. The following
test suite came from Teodor:

Reproduce bug:
initdb and start postmaster
%createdb foo
%psql foo < bug.sql
CREATE TABLE
INSERT 16996 1
INSERT 16997 1
CREATE TABLE
INSERT 17003 1
  ts_name | ts_name
---------+---------
  default | default
  default | default
(2 rows)

VACUUM
ERROR:  datumGetSize: Invalid typLen 0


bug.sql is very simple:
------------------------------------------------
CREATE TABLE pg_ts_cfgmap (
     ts_name text
);

insert into pg_ts_cfgmap values ('default');
insert into pg_ts_cfgmap values ('default');


CREATE TABLE pg_ts_cfg (
     ts_name text
);

insert into pg_ts_cfg values ('default');

select
        *
from
         pg_ts_cfgmap,
         pg_ts_cfg
where
         pg_ts_cfgmap.ts_name = pg_ts_cfg.ts_name;


vacuum analyze pg_ts_cfgmap;

select
         *
from
         pg_ts_cfgmap,
         pg_ts_cfg
where
         pg_ts_cfgmap.ts_name = pg_ts_cfg.ts_name;

---------------------------------------------------

>How-To-Repeat:
See above.
>Fix:
Don't know. This could be related to 64-bit issues.
>Release-Note:
>Audit-Trail:
>Unformatted: