Thread: Status report for 6.5beta on Digital Unix 4.0

Status report for 6.5beta on Digital Unix 4.0

From
"Pedro J. Lobo"
Date:
Hi, people.

I've just compiled and regression-tested 6.5beta (cvsup'ed yesterday) on
Digital Unix 4.0d. I am including a patch which contains modifications for
Makefile.shlib (to add shared library support), and three custom expected
results (because of differences in error messages).

With these patches applied, the following regression tests fail:

- char, varchar, select_implicit, select_having: These fail only when
locale is enabled, due to a bug in the Digital Unix locale libraries. This
problem was discussed before 6.4.2 was released, and is described in the
Digital Unix README.

- abstime, tinterval, horology: These fail with dates that belong to year
1947: the time zone shown for these dates is PDT, instead of the expected
PST. It might be due to a bug in the time zone handling, but I don't know
wether the bug could lie in Digital Unix or the reference platform.
Anyway, all the time-related types seem to be pretty usable.

- geometry: This test fails because of rounding errors. However, the
errors are not limited to the least significant digit. They affect the
last three or four digits. This could be due to the accumulated effect of
rounding errors in intermediate results.

- rules: I get these two errors:

  QUERY: create rule rtest_emp_ins as on insert to rtest_emp do
        insert into rtest_emplog values (new.ename, current_user,
                        'hired', new.salary, '0.00');
+ ERROR:  Bad money external representation 0.00

  QUERY: create rule rtest_emp_del as on delete to rtest_emp do
        insert into rtest_emplog values (old.ename, current_user,
                        'fired', '0.00', old.salary);
+ ERROR:  Bad money external representation 0.00

And later, this one:

  QUERY: update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
! pqReadData() -- backend closed the channel unexpectedly.
!       This probably means the backend terminated abnormally
!       before or while processing the request.
! We have lost the connection to the backend, so further processing is
impossible.  Terminating.

Any comments on this? I could build a version with symbolic information
and play with gdb if someone needs it and knows where should I look at.

I must say that postgres is very close to compile and install right out of
the box on Digital Unix, which has had always (minor) problems.

Cheers,

    Pedro.

--
-------------------------------------------------------------------
Pedro José Lobo Perea                   Tel:    +34 91 336 78 19
Centro de Cálculo                       Fax:    +34 91 331 92 29
E.U.I.T. Telecomunicación               e-mail: pjlobo@euitt.upm.es
Universidad Politécnica de Madrid
Ctra. de Valencia, Km. 7                E-28031 Madrid - España / Spain

Attachment

Re: [PORTS] Status report for 6.5beta on Digital Unix 4.0

From
Bruce Momjian
Date:
Applied.


[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Hi, people.
>
> I've just compiled and regression-tested 6.5beta (cvsup'ed yesterday) on
> Digital Unix 4.0d. I am including a patch which contains modifications for
> Makefile.shlib (to add shared library support), and three custom expected
> results (because of differences in error messages).
>
> With these patches applied, the following regression tests fail:
>
> - char, varchar, select_implicit, select_having: These fail only when
> locale is enabled, due to a bug in the Digital Unix locale libraries. This
> problem was discussed before 6.4.2 was released, and is described in the
> Digital Unix README.
>
> - abstime, tinterval, horology: These fail with dates that belong to year
> 1947: the time zone shown for these dates is PDT, instead of the expected
> PST. It might be due to a bug in the time zone handling, but I don't know
> wether the bug could lie in Digital Unix or the reference platform.
> Anyway, all the time-related types seem to be pretty usable.
>
> - geometry: This test fails because of rounding errors. However, the
> errors are not limited to the least significant digit. They affect the
> last three or four digits. This could be due to the accumulated effect of
> rounding errors in intermediate results.
>
> - rules: I get these two errors:
>
>   QUERY: create rule rtest_emp_ins as on insert to rtest_emp do
>         insert into rtest_emplog values (new.ename, current_user,
>                         'hired', new.salary, '0.00');
> + ERROR:  Bad money external representation 0.00
>
>   QUERY: create rule rtest_emp_del as on delete to rtest_emp do
>         insert into rtest_emplog values (old.ename, current_user,
>                         'fired', '0.00', old.salary);
> + ERROR:  Bad money external representation 0.00
>
> And later, this one:
>
>   QUERY: update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
> ! pqReadData() -- backend closed the channel unexpectedly.
> !       This probably means the backend terminated abnormally
> !       before or while processing the request.
> ! We have lost the connection to the backend, so further processing is
> impossible.  Terminating.
>
> Any comments on this? I could build a version with symbolic information
> and play with gdb if someone needs it and knows where should I look at.
>
> I must say that postgres is very close to compile and install right out of
> the box on Digital Unix, which has had always (minor) problems.
>
> Cheers,
>
>     Pedro.
>
> --
> -------------------------------------------------------------------
> Pedro Jos_ Lobo Perea                   Tel:    +34 91 336 78 19
> Centro de C_lculo                       Fax:    +34 91 331 92 29
> E.U.I.T. Telecomunicaci_n               e-mail: pjlobo@euitt.upm.es
> Universidad Polit_cnica de Madrid
> Ctra. de Valencia, Km. 7                E-28031 Madrid - Espa_a / Spain
Content-Description:

[Attachment, skipping...]


--
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026