Обсуждение: [HACKERS] problems with sunos4 port, endian?
I've been plagued with a connectivity problem to my PostgreSQL database running on a Sparc Sun4 (SunOS 4.1.4) box (both May and 6.1 release versions). I've been trying to use the postODBC drivers and also the pre-built psql.exe client (both under NT) against the sun with no success. The same ODBC and psql programs connect flawlessly to a copy of PostgreSQL running on a FreeBSD box (i386, pg version is dated sometime January). Until today, I figured it was probably some change made to the protocol since the January build which was breaking the earlier compiled clients. However, now I have a situation where I used gcc-cygwin32 to build the psql.exe straight from the 6.1 release source - thereby ensuring my PC client is up to date with the sun server. Suprisingly, the psql.exe file still refused to work with my sun4 box. It worked flawlessly with the FreeBSD box. I've been accessing the database on the sun4 with only 'localhost' connects and I have otherwise had no other problems with the system. The clients on the PC are able to discriminate between valid and invalid database/pguser names. Any form of query or such commands as '\d' or '\l' will sit there forever. ------------------------------
> I've been plagued with a connectivity problem to my PostgreSQL database > running on a Sparc Sun4 (SunOS 4.1.4) box (both May and 6.1 release versions). > > I've been trying to use the postODBC drivers and also the pre-built psql.exe > client (both under NT) against the sun with no success. > > The same ODBC and psql programs connect flawlessly to a copy of PostgreSQL > running on a FreeBSD box (i386, pg version is dated sometime January). > > Until today, I figured it was probably some change made to the protocol since > the January build which was breaking the earlier compiled clients. > > However, now I have a situation where I used gcc-cygwin32 to build the > psql.exe straight from the 6.1 release source - thereby ensuring my PC client > is up to date with the sun server. > > Suprisingly, the psql.exe file still refused to work with my sun4 box. > It worked flawlessly with the FreeBSD box. > > I've been accessing the database on the sun4 with only 'localhost' connects > and I have otherwise had no other problems with the system. > > The clients on the PC are able to discriminate between valid and invalid > database/pguser names. Any form of query or such commands as '\d' or '\l' > will sit there forever. Endian problems with the endian changes to the libpq. Ran into the same situation here. Have our own J/ODBC drivers we had to change...shorts and ints are coming thru big endian instead of little endian. darrenk@insightdist.com ------------------------------
>Endian problems with the endian changes to the libpq. Ran into the same
>situation here. Have our own J/ODBC drivers we had to change...shorts and ints
>are coming thru big endian instead of little endian.
Here is a patch to fix the endian problem of 6.1. With this patch,
your big endian postgres server will begin to speak little endian as
6.0!
Tatsuo Ishii
t-ishii@sra.co.jp
- --------------------------- cut here -----------------------
Index: src/backend/libpq/pqcomprim.c
===================================================================
RCS file: /home/mgr/t-ishii/repository/postgresql-v6.1/src/backend/libpq/pqcomprim.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 pqcomprim.c
*** pqcomprim.c 1997/06/16 01:45:30 1.1.1.1
- --- pqcomprim.c 1997/06/19 01:44:43
***************
*** 24,34 ****
# define hton_l(n) n
#else /* BYTE_ORDER != LITTLE_ENDIAN */
# if BYTE_ORDER == BIG_ENDIAN
! # define ntoh_s(n) (u_short)(((u_char *) &n)[0] << 8 | ((u_char *) &n)[1])
! # define ntoh_l(n) (u_long)(((u_char *)&n)[0] << 24 | \
! ((u_char *)&n)[1] << 16 | \
! ((u_char *)&n)[2] << 8 | ((u_char *)&n)[3])
! # define hton_s(n) (u_short)(((u_char *) &n)[2] << 8 | ((u_char *) &n)[3])
# define hton_l(n) (ntoh_l(n))
# else /* BYTE_ORDER != BIG_ENDIAN */
# if BYTE_ORDER == PDP_ENDIAN
- --- 24,34 ----
# define hton_l(n) n
#else /* BYTE_ORDER != LITTLE_ENDIAN */
# if BYTE_ORDER == BIG_ENDIAN
! # define ntoh_s(n) (u_short)(((u_char *) &n)[1] << 8 | ((u_char *) &n)[0])
! # define ntoh_l(n) (u_long)(((u_char *)&n)[3] << 24 | \
! ((u_char *)&n)[2] << 16 | \
! ((u_char *)&n)[1] << 8 | ((u_char *)&n)[0])
! # define hton_s(n) (ntoh_s(n))
# define hton_l(n) (ntoh_l(n))
# else /* BYTE_ORDER != BIG_ENDIAN */
# if BYTE_ORDER == PDP_ENDIAN
***************
*** 43,51 ****
int pqPutShort(int integer, FILE *f)
{
int retval = 0;
! u_short n;
! n = hton_s(integer);
if(fwrite(&n, sizeof(u_short), 1, f) != 1)
retval = EOF;
- --- 43,52 ----
int pqPutShort(int integer, FILE *f)
{
int retval = 0;
! u_short n,s;
! s = integer;
! n = hton_s(s);
if(fwrite(&n, sizeof(u_short), 1, f) != 1)
retval = EOF;
------------------------------
I would love to here some enlightened opinions on this.
It was my belief that we didn't change the communication in 6.1, and
that all communication between different systems was working properly.
>
> >Endian problems with the endian changes to the libpq. Ran into the same
> >situation here. Have our own J/ODBC drivers we had to change...shorts and ints
> >are coming thru big endian instead of little endian.
>
> Here is a patch to fix the endian problem of 6.1. With this patch,
> your big endian postgres server will begin to speak little endian as
> 6.0!
>
> Tatsuo Ishii
> t-ishii@sra.co.jp
> --------------------------- cut here -----------------------
> Index: src/backend/libpq/pqcomprim.c
> ===================================================================
> RCS file: /home/mgr/t-ishii/repository/postgresql-v6.1/src/backend/libpq/pqcomprim.c,v
> retrieving revision 1.1.1.1
> diff -c -r1.1.1.1 pqcomprim.c
> *** pqcomprim.c 1997/06/16 01:45:30 1.1.1.1
> --- pqcomprim.c 1997/06/19 01:44:43
> ***************
> *** 24,34 ****
> # define hton_l(n) n
> #else /* BYTE_ORDER != LITTLE_ENDIAN */
> # if BYTE_ORDER == BIG_ENDIAN
> ! # define ntoh_s(n) (u_short)(((u_char *) &n)[0] << 8 | ((u_char *) &n)[1])
> ! # define ntoh_l(n) (u_long)(((u_char *)&n)[0] << 24 | \
> ! ((u_char *)&n)[1] << 16 | \
> ! ((u_char *)&n)[2] << 8 | ((u_char *)&n)[3])
> ! # define hton_s(n) (u_short)(((u_char *) &n)[2] << 8 | ((u_char *) &n)[3])
> # define hton_l(n) (ntoh_l(n))
> # else /* BYTE_ORDER != BIG_ENDIAN */
> # if BYTE_ORDER == PDP_ENDIAN
> --- 24,34 ----
> # define hton_l(n) n
> #else /* BYTE_ORDER != LITTLE_ENDIAN */
> # if BYTE_ORDER == BIG_ENDIAN
> ! # define ntoh_s(n) (u_short)(((u_char *) &n)[1] << 8 | ((u_char *) &n)[0])
> ! # define ntoh_l(n) (u_long)(((u_char *)&n)[3] << 24 | \
> ! ((u_char *)&n)[2] << 16 | \
> ! ((u_char *)&n)[1] << 8 | ((u_char *)&n)[0])
> ! # define hton_s(n) (ntoh_s(n))
> # define hton_l(n) (ntoh_l(n))
> # else /* BYTE_ORDER != BIG_ENDIAN */
> # if BYTE_ORDER == PDP_ENDIAN
> ***************
> *** 43,51 ****
> int pqPutShort(int integer, FILE *f)
> {
> int retval = 0;
> ! u_short n;
>
> ! n = hton_s(integer);
> if(fwrite(&n, sizeof(u_short), 1, f) != 1)
> retval = EOF;
>
> --- 43,52 ----
> int pqPutShort(int integer, FILE *f)
> {
> int retval = 0;
> ! u_short n,s;
>
> ! s = integer;
> ! n = hton_s(s);
> if(fwrite(&n, sizeof(u_short), 1, f) != 1)
> retval = EOF;
>
>
>
- --
Bruce Momjian
maillist@candle.pha.pa.us
------------------------------
>I would love to here some enlightened opinions on this. > >It was my belief that we didn't change the communication in 6.1, and >that all communication between different systems was working properly. My experience shows 6.1 cannot communicate if endian is different. Please let me know if I misunderstand anything. INTEL: Intel Linux-ELF system(little endian) SUN: Sun Sparc/SunOS 4.1.4(big endian) PPC: MkLinux-PPC (big endian) INTEL:~$ psql -h SUN template1 Welcome to the POSTGRESQL interactive sql monitor: Please read the file COPYRIGHT for copyright terms of POSTGRESQL type \? for help on slash commands type \q to quit type \g or terminate with semicolon to execute query You are currently connected to the database: template1 template1=> select * from pg_user; <--- psql stucks here I tried other combinations. client(psql) server result - -------------------------------------- INTEL PPC NG INTEL SUN NG PPC INTEL NG PPC SUN OK SUN PPC OK Note that INTEL can talk to 6.0 servers while SUN and PPC can't. - --- Tatsuo Ishii t-ishii@sra.co.jp ------------------------------ End of hackers-digest V1 #391 *****************************
On Thu, 19 Jun 1997, Tatsuo Ishii wrote:
> >I would love to here some enlightened opinions on this.
> >
> >It was my belief that we didn't change the communication in 6.1, and
> >that all communication between different systems was working properly.
>
> My experience shows 6.1 cannot communicate if endian is
> different. Please let me know if I misunderstand anything.
my understanding was that *someone* out there was going to be
working on rewriting the interface to rectify this problem...?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
------------------------------
> > On Thu, 19 Jun 1997, Tatsuo Ishii wrote: > > > >I would love to here some enlightened opinions on this. > > > > > >It was my belief that we didn't change the communication in 6.1, and > > >that all communication between different systems was working properly. > > > > My experience shows 6.1 cannot communicate if endian is > > different. Please let me know if I misunderstand anything. > > my understanding was that *someone* out there was going to be > working on rewriting the interface to rectify this problem...? I thought they were going to change the interface so it communicated in network-standard byte order. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
On Thu, 19 Jun 1997, Bruce Momjian wrote: > > > > On Thu, 19 Jun 1997, Tatsuo Ishii wrote: > > > > my understanding was that *someone* out there was going to be > > working on rewriting the interface to rectify this problem...? > > I thought they were going to change the interface so it communicated in > network-standard byte order. I remember someone saying the same thing. But I don't remember who said this. I think making sure that we use the network-standard byte order is a very good idea. David Friend ! cq995@freenet.carleton.ca Atlantis Scientific Inc. ! david.friend@atlsci.com 20 Colonnade Rd, Suite 110 ! 613-727-1087 (voice) Ottawa, Ontario, CANADA K2E 7M6 ! 800-265-3894 (voice) ERGOvista Scientific Image Analysis ! 613-727-5853 (fax) ------------------------------
> > On Thu, 19 Jun 1997, Bruce Momjian wrote: > > > > > > > On Thu, 19 Jun 1997, Tatsuo Ishii wrote: > > > > > > my understanding was that *someone* out there was going to be > > > working on rewriting the interface to rectify this problem...? > > > > I thought they were going to change the interface so it communicated in > > network-standard byte order. > > I remember someone saying the same thing. But I don't remember who said > this. I think making sure that we use the network-standard byte order > is a very good idea. > Added to TODO list. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
Tatsuo Ishii wrote:
> Here is a patch to fix the endian problem of 6.1. With this patch,
> your big endian postgres server will begin to speak little endian as
> 6.0!
I have tested this patch on my Linux/i686/little-endian machine with
v6.1 and it does not damage my already working installation.
Tatsuo I. reports successful tests on several platforms. I vaguely
recall that someone else reported success on a mixed-endian pair of
platforms. Is there any reason to not introduce it into the source tree?
If no one expresses reservations in the next couple of days, and if no
one claims the job, I will go ahead and commit this to the source tree
as a candidate change for the upcoming jumbo-patch.
- Tom
btw, I used the patch which was re-posted by Tatsuo a couple of days ago
and which included as new patch for postgres.h as well as the original
patch for pqcomprim.c
------------------------------
Thomas,
>Tatsuo Ishii wrote:
>> Here is a patch to fix the endian problem of 6.1. With this patch,
>> your big endian postgres server will begin to speak little endian as
>> 6.0!
>
>I have tested this patch on my Linux/i686/little-endian machine with
>v6.1 and it does not damage my already working installation.
>
>Tatsuo I. reports successful tests on several platforms. I vaguely
>recall that someone else reported success on a mixed-endian pair of
>platforms. Is there any reason to not introduce it into the source tree?
>
>If no one expresses reservations in the next couple of days, and if no
>one claims the job, I will go ahead and commit this to the source tree
>as a candidate change for the upcoming jumbo-patch.
>
> - Tom
>
>btw, I used the patch which was re-posted by Tatsuo a couple of days ago
>and which included as new patch for postgres.h as well as the original
>patch for pqcomprim.c
Sorry. I forgot to explain about this.
pqcomprim.c goes into trouble if BYTE_ORDER macro is not properly
defined. For example, in the src/include/port/sparc_solaris.h there
are statements trying to define the value of BYTE_ORDER macro:
#ifndef BYTE_ORDER
#define BYTE_ORDER BIG_ENDIAN
#endif
Since sparc solaris does not have the endian.h, the value of
BIG_ENDIAN is not defined anywhere. As a result, following statement
in the pqcomprim.c:
#if BYTE_ORDER == LITTLE_ENDIAN
always falls into true. The patch for postgres.h defines values of
BIG_ENDIAN, LITTLE_ENDIAN and PDP_ENDIAN if endian.h does not exist. I
a little bit hesitate to patch postgres.h. But I couldn'y find more
proper place.
- --
Tatsuo Ishii
t-ishii@sra.co.jp
------------------------------
> > Tatsuo Ishii wrote: > > Here is a patch to fix the endian problem of 6.1. With this patch, > > your big endian postgres server will begin to speak little endian as > > 6.0! > > From Thomas: > > I have tested this patch on my Linux/i686/little-endian machine with > v6.1 and it does not damage my already working installation. > > Tatsuo I. reports successful tests on several platforms. I vaguely > recall that someone else reported success on a mixed-endian pair of > platforms. Is there any reason to not introduce it into the source tree? > > If no one expresses reservations in the next couple of days, and if no > one claims the job, I will go ahead and commit this to the source tree > as a candidate change for the upcoming jumbo-patch. I think his original patch was correct. It's the ODBC and JDBC drivers that are not using the network to host long and short. They were assuming little endian, but the correct network way is big endian. Darren darrenk@insightdist.com ------------------------------
> > Tatsuo Ishii wrote: > > Here is a patch to fix the endian problem of 6.1. With this patch, > > your big endian postgres server will begin to speak little endian as > > 6.0! > > I have tested this patch on my Linux/i686/little-endian machine with > v6.1 and it does not damage my already working installation. > > Tatsuo I. reports successful tests on several platforms. I vaguely > recall that someone else reported success on a mixed-endian pair of > platforms. Is there any reason to not introduce it into the source tree? > > If no one expresses reservations in the next couple of days, and if no > one claims the job, I will go ahead and commit this to the source tree > as a candidate change for the upcoming jumbo-patch. > > - Tom > > btw, I used the patch which was re-posted by Tatsuo a couple of days ago > and which included as new patch for postgres.h as well as the original > patch for pqcomprim.c Let's put it in so people can start testing the beta for 6.1p1. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------