Thread: ss_family in hba.c

ss_family in hba.c

From
Bruno Wolff III
Date:
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.


Re: ss_family in hba.c

From
Kurt Roeckx
Date:
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



Re: ss_family in hba.c

From
Mike Aubury
Date:
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;  /*
Forcedesired 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



Re: ss_family in hba.c

From
Bruno Wolff III
Date:
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.


Re: ss_family in hba.c

From
Bruno Wolff III
Date:
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.


Re: ss_family in hba.c

From
Bruno Wolff III
Date:
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.


Re: ss_family in hba.c

From
Kurt Roeckx
Date:
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

psql

From
Nailah Ogeer
Date:
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



Re: psql

From
Bruno Wolff III
Date:
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.

Re: psql

From
Nailah Ogeer
Date:
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.
>


Re: [GENERAL] psql

From
Tom Lane
Date:
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

Re: [GENERAL] psql

From
Nailah Ogeer
Date:
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
>


Re: [GENERAL] psql

From
Sailesh Krishnamurthy
Date:
>>>>> "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


Re: ss_family in hba.c

From
Bruno Wolff III
Date:
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


Re: ss_family in hba.c

From
Bruno Wolff III
Date:
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.


Re: ss_family in hba.c

From
Bruce Momjian
Date:
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

Re: [CYGWIN] ss_family in hba.c

From
Jason Tishler
Date:
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

Re: ss_family in hba.c

From
Kurt Roeckx
Date:
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


Re: ss_family in hba.c

From
Bruce Momjian
Date:
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

Re: ss_family in hba.c

From
Jason Tishler
Date:
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.oprinttup.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

Re: ss_family in hba.c

From
Kurt Roeckx
Date:
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