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; /* 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) ...
Show quoted text
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
Attachments:
sockaddr.difftext/plain; charset=us-asciiDownload+44-10
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:
Show quoted text
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:
Show quoted text
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 19073Here 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 19073Attachments:
/bjm/difftext/plainDownload+157-12
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