Thread: SunOS4 port
So far I think I have done the SunOS4 port except the parallel
regression test. Unfortunately the machine is in production and I
could not increase the shmem parameters. Instead I have done the
serial test and got 4 errors (see attached regression.diffs). Also I
noticed that the test script uses diff -C3 which is not available on
all platforms.
BTW, this effort might be the last one since my company would give up
to maintain SunOS4 machines in the near future.
Karel, Could you check my modifications to formatting.c?
RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v
retrieving revision 1.45
diff -c -r1.45 formatting.c
*** formatting.c 2001/11/19 09:05:01 1.45
--- formatting.c 2001/12/05 02:04:25
***************
*** 4140,4146 **** Np->inout_p += strlen(Np->inout_p) - 1; }
else
! Np->inout_p += sprintf(Np->inout_p, "%15s", Np->number_p) - 1; break;
case NUM_rn:
--- 4140,4149 ---- Np->inout_p += strlen(Np->inout_p) - 1; }
else
! {
! sprintf(Np->inout_p, "%15s", Np->number_p);
! Np->inout_p += strlen(Np->inout_p) - 1;
! } break; case NUM_rn:
***************
*** 4150,4156 **** Np->inout_p += strlen(Np->inout_p) - 1; }
else
! Np->inout_p += sprintf(Np->inout_p, "%15s", str_tolower(Np->number_p)) - 1;
break; case NUM_th:
--- 4153,4162 ---- Np->inout_p += strlen(Np->inout_p) - 1; }
else
! {
! sprintf(Np->inout_p, "%15s", str_tolower(Np->number_p));
! Np->inout_p += strlen(Np->inout_p) - 1;
! } break; case NUM_th:
***************
*** 4664,4670 **** } orgnum = (char *) palloc(MAXFLOATWIDTH + 1);
! len = sprintf(orgnum, "%.0f", fabs(val)); if (Num.pre > len) plen = Num.pre - len;
if (len >= FLT_DIG)
--- 4670,4677 ---- } orgnum = (char *) palloc(MAXFLOATWIDTH + 1);
! sprintf(orgnum, "%.0f", fabs(val));
! len = strlen(orgnum); if (Num.pre > len) plen = Num.pre - len; if (len >=
FLT_DIG)
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> So far I think I have done the SunOS4 port except the parallel
> regression test. Unfortunately the machine is in production and I
> could not increase the shmem parameters. Instead I have done the
> serial test and got 4 errors (see attached regression.diffs).
Most of those look insignificant --- either results of the known
problem that SunOS's atoi doesn't detect overflow, or uninteresting
geometry diffs. But I'm worried about the diffs in the bit test.
Could you look into that?
regards, tom lane
> Tatsuo, > > I've got a SunOS 5.7 machine (in production) which compiles fine. I am > getting the Unix Domain Socket problem in regression (pre parallel > test) however. When I can take it down (next weekend) I will increase the > shm settings but is there anything I should do to get around the domain > socket issue (other than switch to internet server)? I have been working on SunOS4, not Solaris. Anyway, I thought your problem has been solved in current, since the accept queue length in listen() is now expanded, no? -- Tatsuo Ishii
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> The only solution would be having our own memcmp on SunOS4.
Um. Well, we could do that I suppose ... does anyone think
it's worth the trouble?
regards, tom lane
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > So far I think I have done the SunOS4 port except the parallel > > regression test. Unfortunately the machine is in production and I > > could not increase the shmem parameters. Instead I have done the > > serial test and got 4 errors (see attached regression.diffs). > > Most of those look insignificant --- either results of the known > problem that SunOS's atoi doesn't detect overflow, or uninteresting > geometry diffs. But I'm worried about the diffs in the bit test. > Could you look into that? It appears that it at least caused by buggy memcmp() on SunOS4. In bit_cmp(): cmp = memcmp(VARBITS(arg1), VARBITS(arg2), Min(bytelen1,bytelen2)); would return unexpected result if the sign bit of the first byte is on. For example, B'11011000000' is smaller than B'00000000000'. The only solution would be having our own memcmp on SunOS4. -- Tatsuo Ishii
> Tatsuo Ishii <t-ishii@sra.co.jp> writes: > > The only solution would be having our own memcmp on SunOS4. > > Um. Well, we could do that I suppose ... does anyone think > it's worth the trouble? In 7.0 or earlier has a configure check if memcmp is 8 bit clean. In 7.1 someone has removed that test and now we get the failure on SunOS4. -- Tatsuo Ishii
On Wed, Dec 05, 2001 at 11:49:16AM +0900, Tatsuo Ishii wrote: > Karel, Could you check my modifications to formatting.c? It seems right. Thanks. Karel -- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
> > Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > > The only solution would be having our own memcmp on SunOS4.
> >
> > Um. Well, we could do that I suppose ... does anyone think
> > it's worth the trouble?
>
> In 7.0 or earlier has a configure check if memcmp is 8 bit clean. In
> 7.1 someone has removed that test and now we get the failure on
> SunOS4.
I checked out 7.0 using tag REL7_0_PATCHES, and I see this in configure.in:
AC_FUNC_MEMCMP
and this in configure:
echo "$ac_t""$ac_cv_func_memcmp_clean" 1>&6test $ac_cv_func_memcmp_clean = no && LIBOBJS="$LIBOBJS
memcmp.${ac_objext}"
However, I don't see any memcmp.c file, nor in 6.5 either. I wonder if
this was removed from configure.in because it was no longer being used.
The big question is whether we can backpatch in the memcmp code and have
it working cleanly in 7.2.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Hi,
I am trying to debug something on the jdbc list and can't figure out
what is going on here
I'm running postgres 7.1.3 on linux
Here's the table
CREATE TABLE "savingsaccount" ( "id" varchar(3) NOT NULL, "firstname" varchar(24), "lastname" varchar(24),
"balance"numeric(10,2), CONSTRAINT "pk_savings_account" PRIMARY KEY ("id")
);
If I do the select from my machine I get this in the logs
2001-12-05 12:51:47 [3210] DEBUG: query: select id from
savingsaccount where balance between 1 and 200
2001-12-05 12:51:47 [3210] DEBUG: ProcessQuery
2
There is another program running on another machine which get's this
result??
2001-12-05 12:33:56 [3156] DEBUG: query: select id from
savingsaccount where balance between 1.00 and 5.00
2001-12-05 12:33:56 [3156] ERROR: Unable to identify an operator '>='
for types 'numeric' and 'float8'
I even tried with decimals
2001-12-05 12:55:27 [3220] DEBUG: query: select id from
savingsaccount where balance between
0.900000000000000022204460492503130808472
63336181640625 and 199.900000000000005684341886080801486968994140625
2001-12-05 12:55:27 [3220] DEBUG: ProcessQuery
2
Anyone have a clue what's going on here?
Dave
> > In 7.0 or earlier has a configure check if memcmp is 8 bit clean. In
> > 7.1 someone has removed that test and now we get the failure on
> > SunOS4.
>
> I checked out 7.0 using tag REL7_0_PATCHES, and I see this in configure.in:
>
> AC_FUNC_MEMCMP
>
> and this in configure:
>
> echo "$ac_t""$ac_cv_func_memcmp_clean" 1>&6
> test $ac_cv_func_memcmp_clean = no && LIBOBJS="$LIBOBJS memcmp.${ac_objext}"
>
> However, I don't see any memcmp.c file, nor in 6.5 either. I wonder if
> this was removed from configure.in because it was no longer being used.
You are right. It seems the result of configure check has been never
used in any release. The LIBOBJS variable is not used anywhere in any
Makefile. I wonder why we had that check at all. The reason why
non-8bit clean memcmp has not been a problem with SunOS4 port was just
memcmp's return value was evaluated 0 or not. However, bit data type
implementation uses the fact that whether the value is greater than or
less than 0 and bit type appeared since 7.1. I guess that is the
reason why we don't see any memcmp problem before 7.1.
> The big question is whether we can backpatch in the memcmp code and have
> it working cleanly in 7.2.
So there is no such a thing "memcmp code", I guess:-) I think we could
give up the bit data type support for SunOS4 port. Apparently SunOS4
users have not been used bit data type. So we do not make
things worse for 7.2 anyway.
--
Tatsuo Ishii
On Wed, Dec 05, 2001 at 02:19:31PM +0900, Tatsuo Ishii allegedly wrote: > > Tatsuo, > > > > I've got a SunOS 5.7 machine (in production) which compiles fine. I am > > getting the Unix Domain Socket problem in regression (pre parallel > > test) however. When I can take it down (next weekend) I will increase the > > shm settings but is there anything I should do to get around the domain > > socket issue (other than switch to internet server)? > > I have been working on SunOS4, not Solaris. > > Anyway, I thought your problem has been solved in current, since > the accept queue length in listen() is now expanded, no? As far as I know this has indeed been fixed. Cheers, Mathijs
Tatsuo Ishii writes: > The reason why non-8bit clean memcmp has not been a problem with > SunOS4 port was just memcmp's return value was evaluated 0 or not. > However, bit data type implementation uses the fact that whether the > value is greater than or less than 0 and bit type appeared since 7.1. > I guess that is the reason why we don't see any memcmp problem before > 7.1. The return value of memcmp() is also used by bytea and oidvector. As long as you don't need comparison results, and memcmp gives wrong results consistently then you might even get away with it, but a disfunctional oidvector cannot be taken as lightly as the bit types. I've put the SunOS 4 platform under "Unsupported" with the comment "memcmp() does not work correctly, so probably not reliable". Seasoned SunOS 4 users might know what that implies. -- Peter Eisentraut peter_e@gmx.net
> Tatsuo Ishii writes: > > > The reason why non-8bit clean memcmp has not been a problem with > > SunOS4 port was just memcmp's return value was evaluated 0 or not. > > However, bit data type implementation uses the fact that whether the > > value is greater than or less than 0 and bit type appeared since 7.1. > > I guess that is the reason why we don't see any memcmp problem before > > 7.1. > > The return value of memcmp() is also used by bytea and oidvector. As long > as you don't need comparison results, and memcmp gives wrong results > consistently then you might even get away with it, but a disfunctional > oidvector cannot be taken as lightly as the bit types. > > I've put the SunOS 4 platform under "Unsupported" with the comment > "memcmp() does not work correctly, so probably not reliable". Seasoned > SunOS 4 users might know what that implies. I am working with Tatsuo to test the new memcmp.c on SunOS and will report back when the test is completed and all regression tests pass. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Peter Eisentraut <peter_e@gmx.net> writes:
> The return value of memcmp() is also used by bytea and oidvector. As long
> as you don't need comparison results, and memcmp gives wrong results
> consistently then you might even get away with it, but a disfunctional
> oidvector cannot be taken as lightly as the bit types.
oidvector only checks the result for equal or not equal to 0. AFAIK,
the issue with SunOS memcmp is not that it gets equality wrong, it's
that it sorts unequal values wrong. So oidvector will work.
A quick search shows that bit, bytea, and the contrib/tsearch module
are the only places in 7.2 that care about the sign of memcmp's result.
regards, tom lane