Thread: COPY BINARY broken on Linux/AXP
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
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.
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
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
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
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
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