I was looking at this some more and now think there is something wrong
with the references to ss_family rather than a missing inlcude file.
Perhaps those were supposed to be references to sa_family or there
is a missing field from the socket_storage type definition.

Tue, 17 Jun 2003 15:32:32 -0500
Bruno Wolff III <bruno@wolff.to>
ss_family in hba.c
On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> I was looking at this some more and now think there is something wrong
> with the references to ss_family rather than a missing inlcude file.
> Perhaps those were supposed to be references to sa_family or there
> is a missing field from the socket_storage type definition.

The struct sockaddr_storage should only have 1 field you can use
and that is ss_family.  The other fields are there just to get
the right size and padding.

Does your system have it's own (broken?) struct sockaddr_storage
maybe?


Kurt


Tue, 17 Jun 2003 22:49:00 +0200
Kurt Roeckx <Q@ping.be>
Re: ss_family in hba.c
My system has the same problem - struct sockaddr_storage is defined in 
/usr/include/bits/socket.h :

struct sockaddr_storage
  {
    __SOCKADDR_COMMON (__ss_);  /* Address family, etc.  */
    __ss_aligntype __ss_align;  /* Force desired alignment.  */
    char __ss_padding[_SS_PADSIZE];
  };

Where SOCKADDR_COMMON is defined in sockaddr.h as :

#define __SOCKADDR_COMMON(sa_prefix) \
  sa_family_t sa_prefix##family


That means on my machine it needs __ss_family and not ss_family

Kernel 2.4.18
SuSE 7.1


I changed ss_family to __ss_family and it compiles fine (also in an ip.c & 
fe-connect.c IIRC) ...


On Tuesday 17 June 2003 9:49 pm, Kurt Roeckx wrote:
> On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> > I was looking at this some more and now think there is something wrong
> > with the references to ss_family rather than a missing inlcude file.
> > Perhaps those were supposed to be references to sa_family or there
> > is a missing field from the socket_storage type definition.
>
> The struct sockaddr_storage should only have 1 field you can use
> and that is ss_family.  The other fields are there just to get
> the right size and padding.
>
> Does your system have it's own (broken?) struct sockaddr_storage
> maybe?
>
>
> Kurt
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster


Tue, 17 Jun 2003 22:05:06 +0100
Mike Aubury <mike@aubit.com>
Re: ss_family in hba.c
On Tue, Jun 17, 2003 at 22:49:00 +0200,
  Kurt Roeckx <Q@ping.be> wrote:
> On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> > I was looking at this some more and now think there is something wrong
> > with the references to ss_family rather than a missing inlcude file.
> > Perhaps those were supposed to be references to sa_family or there
> > is a missing field from the socket_storage type definition.
> 
> The struct sockaddr_storage should only have 1 field you can use
> and that is ss_family.  The other fields are there just to get
> the right size and padding.
> 
> Does your system have it's own (broken?) struct sockaddr_storage
> maybe?

I am going to look around a bit and see if I can figure this out.
Things worked fine before Bruce changed this stuff. Presumably the
changed code is working for the "core" or the change would have
been reverted days ago.

Tue, 17 Jun 2003 22:47:37 -0500
Bruno Wolff III <bruno@wolff.to>
Re: ss_family in hba.c
On Tue, Jun 17, 2003 at 22:49:00 +0200,
  Kurt Roeckx <Q@ping.be> wrote:
> On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> > I was looking at this some more and now think there is something wrong
> > with the references to ss_family rather than a missing inlcude file.
> > Perhaps those were supposed to be references to sa_family or there
> > is a missing field from the socket_storage type definition.
> 
> The struct sockaddr_storage should only have 1 field you can use
> and that is ss_family.  The other fields are there just to get
> the right size and padding.
> 
> Does your system have it's own (broken?) struct sockaddr_storage
> maybe?

My system does have its own sockaddr_storage definition. I think
it uses __ss_ as the prefix. Also, after looking at the fallback
definition in pqcomm.h, I don't see where that defines ss_family
and hence don't see how that could work.
I am going to see if adding __ works as suggested by someone else
who replied.

Tue, 17 Jun 2003 23:01:27 -0500
Bruno Wolff III <bruno@wolff.to>
Re: ss_family in hba.c
On Tue, Jun 17, 2003 at 23:01:27 -0500,
  Bruno Wolff III <bruno@wolff.to> wrote:
> I am going to see if adding __ works as suggested by someone else
> who replied.

This worked. I think the reason auth.c compiled was because the reference
to ss_family was in conditional code that isn't used on my system.

Tue, 17 Jun 2003 23:07:17 -0500
Bruno Wolff III <bruno@wolff.to>
Re: ss_family in hba.c
On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote:
> 
> My system does have its own sockaddr_storage definition. I think
> it uses __ss_ as the prefix. Also, after looking at the fallback
> definition in pqcomm.h, I don't see where that defines ss_family
> and hence don't see how that could work.
> I am going to see if adding __ works as suggested by someone else
> who replied.

See if this patch helps.

Don't forget to run autoconf after applying the patch.



Kurt
Thu, 19 Jun 2003 23:01:19 +0200
Kurt Roeckx <Q@ping.be>
Re: ss_family in hba.c
What i am trying to do is to maintain a linked list of all the relations
in a database. When i create a db then i want it to insert into the linked
list the relation ids. As it stands now, i can create a db fine and i see
the relation id's in the linked list. BUT, as soon as i psql into the db
then they all disappear. I maintain an array that stores the linked lists
which i initialized in buf_init.
I don't understand this. Can someone explain why? Is it wiping out the
array i initialized before.

signed
please shed some light



Thu, 19 Jun 2003 17:07:43 -0400 (EDT)
Nailah Ogeer <ogeer@cs.queensu.ca>
psql
On Thu, Jun 19, 2003 at 17:07:43 -0400,
  Nailah Ogeer <ogeer@cs.queensu.ca> wrote:

Please don't respond to other messages to start a new thread.

> What i am trying to do is to maintain a linked list of all the relations
> in a database. When i create a db then i want it to insert into the linked
> list the relation ids. As it stands now, i can create a db fine and i see
> the relation id's in the linked list. BUT, as soon as i psql into the db
> then they all disappear. I maintain an array that stores the linked lists
> which i initialized in buf_init.
> I don't understand this. Can someone explain why? Is it wiping out the
> array i initialized before.

You might be better off explaining to us what you are really trying to
do. Information about relations is already in the system catalogs.
Using a linked list in a relation database doesn't work very well.

Thu, 19 Jun 2003 20:49:56 -0500
Bruno Wolff III <bruno@wolff.to>
Re: [HACKERS] psql
what i was trying to do was maintain an array of Buffer pool clusters.
What i did previously was change the pointers around in the freelist so
instead of one i have 4. Now each buffer pool is called a BP cluster.
Within this BP cluster i have things like cluster id, freelist descriptor
etc, and a linked list that holds all the relation id's belonging to that
cluster (right now it does this randomly but we will change this to
grouping according to access patterns). Every time i call
RelationBuildDesc from relcache.c, i randomly assign a cluster id and put
the relation id in the cluster. And every time i want to remove the
relation from the BP i will have to remove it from the linked list of
relation ids. I know that this implementation will not work well for
multi database systems, but this is just the first step of this work.
So what is happening is that i enter the relation ids into the BP cluster
linked list fine and every time i call psql, it automatically deletes.

hope i gave u a better explanation

On Thu, 19 Jun 2003, Bruno Wolff III wrote:

> On Thu, Jun 19, 2003 at 17:07:43 -0400,
>   Nailah Ogeer <ogeer@cs.queensu.ca> wrote:
>
> Please don't respond to other messages to start a new thread.
>
> > What i am trying to do is to maintain a linked list of all the relations
> > in a database. When i create a db then i want it to insert into the linked
> > list the relation ids. As it stands now, i can create a db fine and i see
> > the relation id's in the linked list. BUT, as soon as i psql into the db
> > then they all disappear. I maintain an array that stores the linked lists
> > which i initialized in buf_init.
> > I don't understand this. Can someone explain why? Is it wiping out the
> > array i initialized before.
>
> You might be better off explaining to us what you are really trying to
> do. Information about relations is already in the system catalogs.
> Using a linked list in a relation database doesn't work very well.
>


Fri, 20 Jun 2003 11:00:42 -0400 (EDT)
Nailah Ogeer <ogeer@cs.queensu.ca>
Re: [HACKERS] psql
Nailah Ogeer <ogeer@cs.queensu.ca> writes:
> So what is happening is that i enter the relation ids into the BP cluster
> linked list fine and every time i call psql, it automatically deletes.

Sounds to me like you are trying to keep stuff in backend-local memory
that needs to be in shared memory.

			regards, tom lane

Fri, 20 Jun 2003 13:01:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] psql 
Well here's the thing. Before i was trying to use ShmemInitStruct in
buf_init.c. The problem with this is that you can't shrink or grow shared
memory. That is why i switched over and just used malloc. So i seem to be
in a big dilemma, on one hand, if i use malloc, i can't keep this info i
need; and on the other if i use shmeminitstruct then i can't shrink or
grow the BP clusters.
But i will try to test your hypothesis to see if shared memory will take
care of this.

On Fri, 20 Jun 2003, Tom Lane wrote:

> Nailah Ogeer <ogeer@cs.queensu.ca> writes:
> > So what is happening is that i enter the relation ids into the BP cluster
> > linked list fine and every time i call psql, it automatically deletes.
>
> Sounds to me like you are trying to keep stuff in backend-local memory
> that needs to be in shared memory.
>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>


Fri, 20 Jun 2003 13:32:52 -0400 (EDT)
Nailah Ogeer <ogeer@cs.queensu.ca>
Re: [HACKERS] psql 
>>>>> "Nailah" == Nailah Ogeer <ogeer@cs.queensu.ca> writes:

    Nailah> Well here's the thing. Before i was trying to use
    Nailah> ShmemInitStruct in buf_init.c. The problem with this is
    Nailah> that you can't shrink or grow shared memory. That is why i
    Nailah> switched over and just used malloc. So i seem to be in a

We've implemented a Shared Memory MemoryContext in TelegraphCQ. We
used the opensource libmm from the Apache project. Maybe you can try
using it - it's fairly easy to use. The current version in the web is
based off of 7.2 code, but I hope to refresh with a beta based on 7.3
code in the next few weeks.

http://telegraph.cs.berkeley.edu/telegraphcq

-- 
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh


20 Jun 2003 23:23:08 +0200
Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>
Re: [HACKERS] psql
On Thu, Jun 19, 2003 at 23:01:19 +0200,
  Kurt Roeckx <Q@ping.be> wrote:
> On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote:
> > 
> > My system does have its own sockaddr_storage definition. I think
> > it uses __ss_ as the prefix. Also, after looking at the fallback
> > definition in pqcomm.h, I don't see where that defines ss_family
> > and hence don't see how that could work.
> > I am going to see if adding __ works as suggested by someone else
> > who replied.
> 
> See if this patch helps.
> 
> Don't forget to run autoconf after applying the patch.

I get an error message running autoconf claiming I need to be using
version 2.53 or higher. However, normally I build from CVS without
using it (directly). I run configure and then make. I am guessing
that autoconf is used to make a new configure file from configure.in?
I can see about getting a new version of autoconf up and running.
In the meantime the compile error happens in a different program than
it did previously:
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include   -c printtup.c -o printtup.o
In file included from ../../../../src/include/libpq/libpq-be.h:22,
                 from ../../../../src/include/libpq/libpq.h:21,
                 from printtup.c:20:
../../../../src/include/libpq/pqcomm.h:82: #error struct sockaddr_storage does not provide an ss_family member
make[4]: *** [printtup.o] Error 1

Fri, 20 Jun 2003 18:56:30 -0500
Bruno Wolff III <bruno@wolff.to>
Re: ss_family in hba.c
On Fri, Jun 20, 2003 at 18:56:30 -0500,
  Bruno Wolff III <bruno@wolff.to> wrote:
> On Thu, Jun 19, 2003 at 23:01:19 +0200,
>   Kurt Roeckx <Q@ping.be> wrote:
> > On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote:
> > > 
> > > My system does have its own sockaddr_storage definition. I think
> > > it uses __ss_ as the prefix. Also, after looking at the fallback
> > > definition in pqcomm.h, I don't see where that defines ss_family
> > > and hence don't see how that could work.
> > > I am going to see if adding __ works as suggested by someone else
> > > who replied.
> > 
> > See if this patch helps.
> > 
> > Don't forget to run autoconf after applying the patch.
> 
> I get an error message running autoconf claiming I need to be using
> version 2.53 or higher. However, normally I build from CVS without

After getting 2.57 everything seems to be working OK. So the patch seems
good from my end.

Fri, 20 Jun 2003 19:19:21 -0500
Bruno Wolff III <bruno@wolff.to>
Re: ss_family in hba.c

I have applied a patch to CVS to fix the problem.  It is all your patch,
except for the part you got from me, which was wrong.  :-(

It took me a while to realize the subtlety of your patch.  First, it
removes the use of sa_family_t _except_ for cases that don't have
SOCKADDR_STORAGE, where it is required.  Second, it allows for a
structure member named ss_family or __ss_family, tested via configure.

This should fix most platforms.  I am not sure how cygwin is going to
handle this --- we might have to add a specific sa_family_t typedef for
that platform --- MinGW does have sa_family_t, but probably doesn't need
it anyway.  Testing for the size of sa_family_t is possible via
configure, but if only cygwin needs it, we can just hard-code that
platform in the template files.  Cygwin folks, would you test CVS and
let me know.

---------------------------------------------------------------------------

Kurt Roeckx wrote:
> On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote:
> > 
> > My system does have its own sockaddr_storage definition. I think
> > it uses __ss_ as the prefix. Also, after looking at the fallback
> > definition in pqcomm.h, I don't see where that defines ss_family
> > and hence don't see how that could work.
> > I am going to see if adding __ works as suggested by someone else
> > who replied.
> 
> See if this patch helps.
> 
> Don't forget to run autoconf after applying the patch.
> 
> 
> 
> Kurt
> 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Mon, 23 Jun 2003 19:49:11 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ss_family in hba.c
Here is the patch, to the patches list.

---------------------------------------------------------------------------

Kurt Roeckx wrote:
> On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote:
> > 
> > My system does have its own sockaddr_storage definition. I think
> > it uses __ss_ as the prefix. Also, after looking at the fallback
> > definition in pqcomm.h, I don't see where that defines ss_family
> > and hence don't see how that could work.
> > I am going to see if adding __ works as suggested by someone else
> > who replied.
> 
> See if this patch helps.
> 
> Don't forget to run autoconf after applying the patch.
> 
> 
> 
> Kurt
> 

[ Attachment, skipping... ]

> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo@postgresql.org so that your
>       message can get through to the mailing list cleanly

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Index: configure
===================================================================
RCS file: /cvsroot/pgsql-server/configure,v
retrieving revision 1.275
diff -c -c -r1.275 configure
*** configure	18 Jun 2003 16:04:15 -0000	1.275
--- configure	23 Jun 2003 23:37:54 -0000
***************
*** 9871,9876 ****
--- 9871,9997 ----
  
  fi
  
+ echo "$as_me:$LINENO: checking for struct sockaddr_storage.ss_family" >&5
+ echo $ECHO_N "checking for struct sockaddr_storage.ss_family... $ECHO_C" >&6
+ if test "${ac_cv_member_struct_sockaddr_storage_ss_family+set}" = set; then
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+   cat >conftest.$ac_ext <<_ACEOF
+ #line $LINENO "configure"
+ #include "confdefs.h"
+ #include <sys/types.h>
+ #ifdef HAVE_SYS_SOCKET_H
+ #include <sys/socket.h>
+ #endif
+ 
+ 
+ #ifdef F77_DUMMY_MAIN
+ #  ifdef __cplusplus
+      extern "C"
+ #  endif
+    int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+ static struct sockaddr_storage ac_aggr;
+ if (ac_aggr.ss_family)
+ return 0;
+   ;
+   return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+   (eval $ac_compile) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); } &&
+          { ac_try='test -s conftest.$ac_objext'
+   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+   (eval $ac_try) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); }; }; then
+   ac_cv_member_struct_sockaddr_storage_ss_family=yes
+ else
+   echo "$as_me: failed program was:" >&5
+ cat conftest.$ac_ext >&5
+ ac_cv_member_struct_sockaddr_storage_ss_family=no
+ fi
+ rm -f conftest.$ac_objext conftest.$ac_ext
+ fi
+ echo "$as_me:$LINENO: result: $ac_cv_member_struct_sockaddr_storage_ss_family" >&5
+ echo "${ECHO_T}$ac_cv_member_struct_sockaddr_storage_ss_family" >&6
+ if test $ac_cv_member_struct_sockaddr_storage_ss_family = yes; then
+ 
+ cat >>confdefs.h <<_ACEOF
+ #define HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY 1
+ _ACEOF
+ 
+ 
+ fi
+ echo "$as_me:$LINENO: checking for struct sockaddr_storage.__ss_family" >&5
+ echo $ECHO_N "checking for struct sockaddr_storage.__ss_family... $ECHO_C" >&6
+ if test "${ac_cv_member_struct_sockaddr_storage___ss_family+set}" = set; then
+   echo $ECHO_N "(cached) $ECHO_C" >&6
+ else
+   cat >conftest.$ac_ext <<_ACEOF
+ #line $LINENO "configure"
+ #include "confdefs.h"
+ #include <sys/types.h>
+ #ifdef HAVE_SYS_SOCKET_H
+ #include <sys/socket.h>
+ #endif
+ 
+ 
+ #ifdef F77_DUMMY_MAIN
+ #  ifdef __cplusplus
+      extern "C"
+ #  endif
+    int F77_DUMMY_MAIN() { return 1; }
+ #endif
+ int
+ main ()
+ {
+ static struct sockaddr_storage ac_aggr;
+ if (ac_aggr.__ss_family)
+ return 0;
+   ;
+   return 0;
+ }
+ _ACEOF
+ rm -f conftest.$ac_objext
+ if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+   (eval $ac_compile) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); } &&
+          { ac_try='test -s conftest.$ac_objext'
+   { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+   (eval $ac_try) 2>&5
+   ac_status=$?
+   echo "$as_me:$LINENO: \$? = $ac_status" >&5
+   (exit $ac_status); }; }; then
+   ac_cv_member_struct_sockaddr_storage___ss_family=yes
+ else
+   echo "$as_me: failed program was:" >&5
+ cat conftest.$ac_ext >&5
+ ac_cv_member_struct_sockaddr_storage___ss_family=no
+ fi
+ rm -f conftest.$ac_objext conftest.$ac_ext
+ fi
+ echo "$as_me:$LINENO: result: $ac_cv_member_struct_sockaddr_storage___ss_family" >&5
+ echo "${ECHO_T}$ac_cv_member_struct_sockaddr_storage___ss_family" >&6
+ if test $ac_cv_member_struct_sockaddr_storage___ss_family = yes; then
+ 
+ cat >>confdefs.h <<_ACEOF
+ #define HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY 1
+ _ACEOF
+ 
+ 
+ fi
+ 
  echo "$as_me:$LINENO: checking for struct addrinfo" >&5
  echo $ECHO_N "checking for struct addrinfo... $ECHO_C" >&6
  if test "${ac_cv_type_struct_addrinfo+set}" = set; then
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.266
diff -c -c -r1.266 configure.in
*** configure.in	18 Jun 2003 16:04:15 -0000	1.266
--- configure.in	23 Jun 2003 23:37:55 -0000
***************
*** 778,783 ****
--- 778,784 ----
  PGAC_UNION_SEMUN
  PGAC_STRUCT_SOCKADDR_UN
  PGAC_STRUCT_SOCKADDR_STORAGE
+ PGAC_STRUCT_SOCKADDR_STORAGE_SS_FAMILY
  PGAC_STRUCT_ADDRINFO
  
  AC_CHECK_TYPES([struct cmsgcred, struct fcred, struct sockcred], [], [],
Index: config/c-library.m4
===================================================================
RCS file: /cvsroot/pgsql-server/config/c-library.m4,v
retrieving revision 1.21
diff -c -c -r1.21 c-library.m4
*** config/c-library.m4	12 Jun 2003 16:05:10 -0000	1.21
--- config/c-library.m4	23 Jun 2003 23:37:55 -0000
***************
*** 110,115 ****
--- 110,128 ----
  #endif
  ])])# PGAC_STRUCT_SOCKADDR_STORAGE
  
+ # PGAC_STRUCT_SOCKADDR_STORAGE_SS_FAMILY
+ # --------------------------------------
+ # This checks if the struct sockaddr has a proper ss_family and not an
+ # __ss_family as rfc2553 defined.
+ AC_DEFUN([PGAC_STRUCT_SOCKADDR_STORAGE_SS_FAMILY],
+ [AC_CHECK_MEMBERS([struct sockaddr_storage.ss_family,
+ 	struct sockaddr_storage.__ss_family], [], [],
+ [#include <sys/types.h>
+ #ifdef HAVE_SYS_SOCKET_H
+ #include <sys/socket.h>
+ #endif
+ ])])# PGAC_STRUCT_SOCKADDR_STORAGE_SS_FAMILY
+ 
  
  # PGAC_STRUCT_ADDRINFO
  # -----------------------
Index: src/include/pg_config.h.in
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v
retrieving revision 1.53
diff -c -c -r1.53 pg_config.h.in
*** src/include/pg_config.h.in	15 Jun 2003 04:09:18 -0000	1.53
--- src/include/pg_config.h.in	23 Jun 2003 23:38:02 -0000
***************
*** 423,428 ****
--- 423,434 ----
  /* Define to 1 if the system has the type `struct sockaddr_storage'. */
  #undef HAVE_STRUCT_SOCKADDR_STORAGE
  
+ /* Define to 1 if `ss_family' is member of `struct sockaddr_storage'. */
+ #undef HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY
+ 
+ /* Define to 1 if `__ss_family' is member of `struct sockaddr_storage'. */
+ #undef HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY
+ 
  /* Define to 1 if the system has the type `struct sockaddr_un'. */
  #undef HAVE_STRUCT_SOCKADDR_UN
  
Index: src/include/libpq/pqcomm.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/libpq/pqcomm.h,v
retrieving revision 1.86
diff -c -c -r1.86 pqcomm.h
*** src/include/libpq/pqcomm.h	12 Jun 2003 07:36:51 -0000	1.86
--- src/include/libpq/pqcomm.h	23 Jun 2003 23:38:02 -0000
***************
*** 65,70 ****
--- 65,76 ----
  		 * _SS_MAXSIZE value minus size of ss_family
  		 * __ss_pad1, __ss_align fields is 112 */
  };
+ #elif !defined(HAVE_STRUCT_SOCKADDR_STORAGE_SS_FAMILY)
+ # ifdef HAVE_STRUCT_SOCKADDR_STORAGE___SS_FAMILY
+ #  define ss_family __ss_family
+ # else
+ #  error struct sockaddr_storage does not provide an ss_family member
+ # endif
  #endif
  
  typedef struct {
Index: src/port/getaddrinfo.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/port/getaddrinfo.c,v
retrieving revision 1.8
diff -c -c -r1.8 getaddrinfo.c
*** src/port/getaddrinfo.c	14 Jun 2003 18:20:33 -0000	1.8
--- src/port/getaddrinfo.c	23 Jun 2003 23:38:03 -0000
***************
*** 220,226 ****
  		char *node, int nodelen,
  		char *service, int servicelen, int flags)
  {
- 	sa_family_t	family;
  	int		ret = -1;
  
  	/* Invalid arguments. */
--- 220,225 ----
***************
*** 236,244 ****
  		return EAI_FAIL;
  	}
  
- 	family = sa->sa_family;
  #ifdef	HAVE_IPV6
! 	if (family == AF_INET6)
  	{
  		return	EAI_FAMILY;
  	}
--- 235,242 ----
  		return EAI_FAIL;
  	}
  
  #ifdef	HAVE_IPV6
! 	if (sa->sa_family == AF_INET6)
  	{
  		return	EAI_FAMILY;
  	}
***************
*** 246,258 ****
  
  	if (service)
  	{
! 		if (family == AF_INET)
  		{
  			ret = snprintf(service, servicelen, "%d",
  				ntohs(((struct sockaddr_in *)sa)->sin_port));
  		}
  #ifdef	HAVE_UNIX_SOCKETS
! 		else if (family == AF_UNIX)
  		{
  			ret = snprintf(service, servicelen, "%s",
  				((struct sockaddr_un *)sa)->sun_path);
--- 244,256 ----
  
  	if (service)
  	{
! 		if (sa->sa_family == AF_INET)
  		{
  			ret = snprintf(service, servicelen, "%d",
  				ntohs(((struct sockaddr_in *)sa)->sin_port));
  		}
  #ifdef	HAVE_UNIX_SOCKETS
! 		else if (sa->sa_family == AF_UNIX)
  		{
  			ret = snprintf(service, servicelen, "%s",
  				((struct sockaddr_un *)sa)->sun_path);
***************
*** 266,279 ****
  
  	if (node)
  	{
! 		if (family == AF_INET)
  		{
  			char	*p;
  			p = inet_ntoa(((struct sockaddr_in *)sa)->sin_addr);
  			ret = snprintf(node, nodelen, "%s", p);
  		}
  #ifdef	HAVE_UNIX_SOCKETS
! 		else if (family == AF_UNIX)
  		{
  			ret = snprintf(node, nodelen, "%s", "localhost");
  		}
--- 264,277 ----
  
  	if (node)
  	{
! 		if (sa->sa_family == AF_INET)
  		{
  			char	*p;
  			p = inet_ntoa(((struct sockaddr_in *)sa)->sin_addr);
  			ret = snprintf(node, nodelen, "%s", p);
  		}
  #ifdef	HAVE_UNIX_SOCKETS
! 		else if (sa->sa_family == AF_UNIX)
  		{
  			ret = snprintf(node, nodelen, "%s", "localhost");
  		}
Mon, 23 Jun 2003 19:49:26 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ss_family in hba.c
Bruce,

On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote:
> This should fix most platforms.  I am not sure how cygwin is going to
> handle this --- we might have to add a specific sa_family_t typedef
> for that platform --- MinGW does have sa_family_t, but probably
> doesn't need it anyway.  Testing for the size of sa_family_t is
> possible via configure, but if only cygwin needs it, we can just
> hard-code that platform in the template files.  Cygwin folks, would
> you test CVS and let me know.

The above seems to be OK for Cygwin too.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Tue, 24 Jun 2003 08:12:30 -0400
Jason Tishler <jason@tishler.net>
Re: [HACKERS] ss_family in hba.c
On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote:
> 
> I have applied a patch to CVS to fix the problem.  It is all your patch,
> except for the part you got from me, which was wrong.  :-(
> 
> It took me a while to realize the subtlety of your patch.  First, it
> removes the use of sa_family_t _except_ for cases that don't have
> SOCKADDR_STORAGE, where it is required.  Second, it allows for a
> structure member named ss_family or __ss_family, tested via configure.
> 
> This should fix most platforms.  I am not sure how cygwin is going to
> handle this --- we might have to add a specific sa_family_t typedef for
> that platform --- MinGW does have sa_family_t, but probably doesn't need
> it anyway.  Testing for the size of sa_family_t is possible via
> configure, but if only cygwin needs it, we can just hard-code that
> platform in the template files.  Cygwin folks, would you test CVS and
> let me know.

There are probably other systems that don't have sa_family_t yet,
but they should be rather old.  Even my Solaris 2.6 already seems
to have it.

What I was confused about is, is that cygwin seems to have a
struct sockaddr_storage in the first place (in winsock2.h).  I'm
not sure what problem he really had since he only told it how he
solved it.

All that probably needed to change for cygwin was to no longer
use sa_family_t in the getaddrinfo.c.


Kurt


Tue, 24 Jun 2003 19:02:14 +0200
Kurt Roeckx <Q@ping.be>
Re: [HACKERS] ss_family in hba.c
Kurt Roeckx wrote:
> On Mon, Jun 23, 2003 at 07:49:11PM -0400, Bruce Momjian wrote:
> > 
> > I have applied a patch to CVS to fix the problem.  It is all your patch,
> > except for the part you got from me, which was wrong.  :-(
> > 
> > It took me a while to realize the subtlety of your patch.  First, it
> > removes the use of sa_family_t _except_ for cases that don't have
> > SOCKADDR_STORAGE, where it is required.  Second, it allows for a
> > structure member named ss_family or __ss_family, tested via configure.
> > 
> > This should fix most platforms.  I am not sure how cygwin is going to
> > handle this --- we might have to add a specific sa_family_t typedef for
> > that platform --- MinGW does have sa_family_t, but probably doesn't need
> > it anyway.  Testing for the size of sa_family_t is possible via
> > configure, but if only cygwin needs it, we can just hard-code that
> > platform in the template files.  Cygwin folks, would you test CVS and
> > let me know.
> 
> There are probably other systems that don't have sa_family_t yet,
> but they should be rather old.  Even my Solaris 2.6 already seems
> to have it.
> 
> What I was confused about is, is that cygwin seems to have a
> struct sockaddr_storage in the first place (in winsock2.h).  I'm
> not sure what problem he really had since he only told it how he
> solved it.
> 
> All that probably needed to change for cygwin was to no longer
> use sa_family_t in the getaddrinfo.c.

But Jason reported he needed that typedef for sa_family_t.  Jason, is
that accurate.  If you remove the Cygwin typedef in pqcomm.h, does the
compile fail?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 24 Jun 2003 15:04:05 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] ss_family in hba.c
Bruce,

On Tue, Jun 24, 2003 at 03:04:05PM -0400, Bruce Momjian wrote:
> Kurt Roeckx wrote:
> > All that probably needed to change for cygwin was to no longer
> > use sa_family_t in the getaddrinfo.c.
> 
> But Jason reported he needed that typedef for sa_family_t.  Jason, is
> that accurate.

Yes.

> If you remove the Cygwin typedef in pqcomm.h, does the compile fail?

Yes:

    gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include  -DBUILDING_DLL  -c -o printtup.o printtup.c
    In file included from ../../../../src/include/libpq/libpq-be.h:22,
                     from ../../../../src/include/libpq/libpq.h:21,
                     from printtup.c:20:
    ../../../../src/include/libpq/pqcomm.h:54: parse error before "sa_family_t"
    [snip]

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

Tue, 24 Jun 2003 16:10:13 -0400
Jason Tishler <jason@tishler.net>
Re: [HACKERS] ss_family in hba.c
On Tue, Jun 24, 2003 at 04:10:13PM -0400, Jason Tishler wrote:
> Bruce,
> 
> On Tue, Jun 24, 2003 at 03:04:05PM -0400, Bruce Momjian wrote:
> > Kurt Roeckx wrote:
> > > All that probably needed to change for cygwin was to no longer
> > > use sa_family_t in the getaddrinfo.c.
> > 
> > But Jason reported he needed that typedef for sa_family_t.  Jason, is
> > that accurate.
> 
> Yes.
> 
> > If you remove the Cygwin typedef in pqcomm.h, does the compile fail?

It seems that struct sockaddr_storage is defined in winsock2.h,
but that is only included in the win32 port.

Maybe the right solution is the include that winsock2.h instead
(through windows.h?)  And make sure configure also includes it
when doing the checks.

The headers even seem to define struct sockaddr_in6, getaddrinfo
and getnameinfo, so I wonder if cygwin supports ipv6 or not.


Kurt


Wed, 25 Jun 2003 18:06:31 +0200
Kurt Roeckx <Q@ping.be>
Re: [HACKERS] ss_family in hba.c