Thread: ss_family in hba.c
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.
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
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
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.
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.
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.
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
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
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.
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. >
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
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 >
>>>>> "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
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
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.
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
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
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
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
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
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