Horton

Thread

  1. COPY BINARY broken on Linux/AXP

    PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2001-06-27T15:15:23Z

    Reinhard Max (max@suse.de) reports a bug with a severity of 3
The lower the number the more severe it is.

Short Description
COPY BINARY broken on Linux/AXP

Long Description
On SuSE Linux for the Alpha(AXP) architecture 'COPY BINARY FROM'
seems not to be able to read a file that was generated by
'COPY BINARY TO' before. Therefore the regression test fails
on test 'misc'.
On our other architectures (i386, IA-64, S390) everything is fine.

I'v copied the first hunk of regression.diffs to the example code
section. There are more hunks, but they seem only to be a result of
the failed 'COPY FROM'.


Sample Code
*** ./expected/misc.out Wed Jun 27 14:35:40 2001
--- ./results/misc.out  Wed Jun 27 14:37:03 2001
***************
*** 61,73 ****
  COPY BINARY stud_emp TO '/usr/src/packages/BUILD/postgresql-7.1.2/src/test/regress/results/stud_emp.data';
  DELETE FROM stud_emp;
  COPY BINARY stud_emp FROM '/usr/src/packages/BUILD/postgresql-7.1.2/src/test/regress/results/stud_emp.data';
  SELECT * FROM stud_emp;
   name  | age |  location  | salary | manager | gpa | percent 
! -------+-----+------------+--------+---------+-----+---------
!  jeff  |  23 | (8,7.7)    |    600 | sharon  | 3.5 |        
!  cim   |  30 | (10.5,4.7) |    400 |         | 3.4 |        
!  linda |  19 | (0.9,6.1)  |    100 |         | 2.9 |        
! (3 rows)
  
  -- COPY aggtest FROM stdin;
  -- 56 7.8
--- 61,71 ----
  COPY BINARY stud_emp TO '/usr/src/packages/BUILD/postgresql-7.1.2/src/test/regress/results/stud_emp.data';
  DELETE FROM stud_emp;
  COPY BINARY stud_emp FROM '/usr/src/packages/BUILD/postgresql-7.1.2/src/test/regress/results/stud_emp.data';
+ ERROR:  copy: line 1, COPY BINARY: sizeof(field 3) is 0, expected 16
  SELECT * FROM stud_emp;
   name | age | location | salary | manager | gpa | percent 
! ------+-----+----------+--------+---------+-----+---------
! (0 rows)
  
  -- COPY aggtest FROM stdin;
  -- 56 7.8


No file was uploaded with this report

  2. Re: COPY BINARY broken on Linux/AXP

    Reinhard Max <max@suse.de> — 2001-06-27T15:34:43Z

    Hi,

On Wed, 27 Jun 2001 pgsql-bugs@postgresql.org wrote:

> On SuSE Linux for the Alpha(AXP) architecture 'COPY BINARY FROM'
> seems not to be able to read a file that was generated by
> 'COPY BINARY TO' before. Therefore the regression test fails
> on test 'misc'.

Oops, I forgot to mention the version: postgresql-7.1.2

cu
	Reinhard
-- 
If you put garbage in a computer  nothing comes out but  garbage.
But this garbage, having passed through a very expensive machine,
is somehow enobled and none dare criticize it.

  3. Re: COPY BINARY broken on Linux/AXP

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-06-27T15:50:50Z

    pgsql-bugs@postgresql.org writes:
> On SuSE Linux for the Alpha(AXP) architecture 'COPY BINARY FROM'
> seems not to be able to read a file that was generated by
> 'COPY BINARY TO' before.

Hmm.  The regression tests do pass on other Linux/Alpha platforms.
Could you look at the generated file and see if it seems correct
or not?  (The format is documented on the COPY reference page ---
note that it is different in 7.1 than it was in prior releases.)

			regards, tom lane

  4. Re: COPY BINARY broken on Linux/AXP

    Reinhard Max <max@suse.de> — 2001-06-27T16:27:15Z

    On Wed, 27 Jun 2001, Tom Lane wrote:

> pgsql-bugs@postgresql.org writes:
> > On SuSE Linux for the Alpha(AXP) architecture 'COPY BINARY FROM'
> > seems not to be able to read a file that was generated by
> > 'COPY BINARY TO' before.
>
> Hmm.  The regression tests do pass on other Linux/Alpha platforms.

I was checking it on our current development version.

Meanwhile, I re-checked it on SuSE Linux 7.1 AXP and here it works.

Interestingly, the results of the geometry tests differ also between
the two versions of Linux, I've tested. On SuSE Linux 7.1 the results
are the same as in geometry-solaris-precision.out while the
development version's results are identical to
geometry-alpha-precision.

I suspect that the newer versions of gcc or glibc are the source of
these problems. Let's see what our Alpha experts say about this...

> Could you look at the generated file and see if it seems correct
> or not?  (The format is documented on the COPY reference page ---
> note that it is different in 7.1 than it was in prior releases.)

It looks at least similar to the example in the manpage:

# od -c results/stud_emp.data
0000000   P   G   B   C   O   P   Y  \n 377  \r  \n  \0 004 003 002 001
0000020  \0  \0  \0  \0  \0  \0  \0  \0  \a  \0 377 377  \b  \0  \0  \0
0000040   j   e   f   f 004  \0 027  \0  \0  \0 020  \0  \0  \0  \0  \0
0000060  \0  \0       @ 315 314 314 314 314 314 036   @ 004  \0   X 002
0000100  \0  \0      \0   s   h   a   r   o   n  \0  \0  \0  \0  \0  \0
0000120  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000140  \0  \0  \0  \0  \b  \0  \0  \0  \0  \0  \0  \0  \f   @  \0  \0
0000160  \a  \0 377 377  \a  \0  \0  \0   c   i   m 004  \0 036  \0  \0
0000200  \0 020  \0  \0  \0  \0  \0  \0  \0   %   @ 315 314 314 314 314
0000220 314 022   @ 004  \0 220 001  \0  \0  \0  \0  \b  \0   3   3   3
0000240   3   3   3  \v   @  \0  \0  \a  \0 377 377  \t  \0  \0  \0   l
0000260   i   n   d   a 004  \0 023  \0  \0  \0 020  \0 315 314 314 314
0000300 314 314 354   ?   f   f   f   f   f   f 030   @ 004  \0   d  \0
0000320  \0  \0  \0  \0  \b  \0   3   3   3   3   3   3  \a   @  \0  \0
0000340 377 377
0000342

cu
	Reinhard

  5. Re: COPY BINARY broken on Linux/AXP

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-06-27T16:41:47Z

    Reinhard Max <max@suse.de> writes:
> I suspect that the newer versions of gcc or glibc are the source of
> these problems. Let's see what our Alpha experts say about this...

Okay.  If it proves to be a portability problem rather than a compiler
bug, let us know ...

>> Could you look at the generated file and see if it seems correct
>> or not?  (The format is documented on the COPY reference page ---
>> note that it is different in 7.1 than it was in prior releases.)

> It looks at least similar to the example in the manpage:

It looks okay to me --- at least the length of field three looks correct
in each tuple.  The problem must be on the reading side.

			regards, tom lane

  6. Re: COPY BINARY broken on Linux/AXP

    Reinhard Max <max@suse.de> — 2001-06-29T08:24:24Z

    Hi,

On Wed, 27 Jun 2001, Tom Lane wrote:

> Reinhard Max <max@suse.de> writes:
> > I suspect that the newer versions of gcc or glibc are the source of
> > these problems. Let's see what our Alpha experts say about this...
>
> Okay.  If it proves to be a portability problem rather than a
> compiler bug, let us know ...

... it really was the compiler. Sorry for bothering you.

What will remain is the differences in the results of the geometry
test. This is due to the fact that glibc-2.2.3 uses a different (and
more precise, as I've been told) implementation for the trigonometric
functions.

Is there a way to reflect that fact in /src/test/regress/resultmap so
that the results of both glibc<2.2.3 and glibc>=2.2.3 get compared
with thir respective expected results?

cu
	Reinhard

  7. Re: COPY BINARY broken on Linux/AXP

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-06-29T14:20:40Z

    Reinhard Max <max@suse.de> writes:
> Is there a way to reflect that fact in /src/test/regress/resultmap so
> that the results of both glibc<2.2.3 and glibc>=2.2.3 get compared
> with thir respective expected results?

Hmm.  We currently have mechanisms for allowing result files to vary
depending on platform (config.guess output) and compiler (cc vs gcc),
but not on libc version.  I'm not real eager to add yet another
frammish for that, anyway.  We've talked in the past about making it
possible to suppress the last digit or two of floating-point display,
which should eliminate most of the cross-platform differences in
geometry output.  I think moving that task up the priority list is a
more appropriate response.

			regards, tom lane