Re: [HACKERS] OSF build fixed
On Wed, 16 Jul 2003 03:56 am, Tom Lane wrote: osf-template.patch: adds pthread support for OSF tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha) Applied; it would be a good idea to get some more testing of it, but that's what beta is for ... Yes, I only have access to one version of Tru64, so all I can assert is that it works for me, and that is only for a fairly simple test case so far. I'd be much more comfortable if other OSF users could test too. I can supply the simple ECPG app I've been using. Regards, Philip. [back from holidays and catching up on a staggering volume of PostgreSQL mail] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OSF build fixed
Philip Yarra [EMAIL PROTECTED] writes: int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h tested on RedHat Linux 7.3 and OSF Applied (along with some further hacking to make the struct padding logic more robust). osf-template.patch: adds pthread support for OSF tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha) Applied; it would be a good idea to get some more testing of it, but that's what beta is for ... regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] OSF build fixed
On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote: Philip Yarra [EMAIL PROTECTED] writes: int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h tested on RedHat Linux 7.3 and OSF Applied (along with some further hacking to make the struct padding logic more robust). I'm not sure what you did exactly, or why you think it's better. But it seems you removed the 6 byte pad, between the ss_family and the __ss_align, and I have no idea why. I won't say that I fully understand allignment as is defined in the C standard(s), but I do know that it doesn't have to allign an int64 to a multiple of 8 byte address. Note that I didn't just make that structure up, other people did. It's for instance like that in the RFC and in SUS v3. Kurt ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] OSF build fixed
Kurt Roeckx [EMAIL PROTECTED] writes: On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote: Applied (along with some further hacking to make the struct padding logic more robust). I'm not sure what you did exactly, or why you think it's better. But it seems you removed the 6 byte pad, between the ss_family and the __ss_align, and I have no idea why. If the pad is needed, it'll be there. Making it explicit doesn't buy anything. Note that I didn't just make that structure up, other people did. It's for instance like that in the RFC and in SUS v3. I wouldn't have touched it if the code actually worked, but it does not work as intended once you stick in the #ifdef SALEN thingy. The padding computation was not accounting for that. To make it work correctly we'd have had to add an additional explicit pad field ... which, if sa_family_t happened to be char and not short, would be a zero-element array, resulting in a compile failure. As I see it, there are two things this struct declaration is trying to do: make sure the struct is of total size 128 bytes, and make sure it has alignment as good as the worst-case alignment requirement that the platform has for integer datatypes. (We assume that sockaddr is unlikely to contain any float fields ;-), so we need not worry about the prospect that floats might have stronger alignment requirement than int64.) The revised code accomplishes both those things. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] OSF build fixed
On Tue, Jul 15, 2003 at 04:28:49PM -0400, Tom Lane wrote: Kurt Roeckx [EMAIL PROTECTED] writes: On Tue, Jul 15, 2003 at 01:56:55PM -0400, Tom Lane wrote: Applied (along with some further hacking to make the struct padding logic more robust). I'm not sure what you did exactly, or why you think it's better. But it seems you removed the 6 byte pad, between the ss_family and the __ss_align, and I have no idea why. If the pad is needed, it'll be there. Making it explicit doesn't buy anything. Note that I didn't just make that structure up, other people did. It's for instance like that in the RFC and in SUS v3. I wouldn't have touched it if the code actually worked, but it does not work as intended once you stick in the #ifdef SALEN thingy. The padding computation was not accounting for that. To make it work correctly we'd have had to add an additional explicit pad field ... which, if sa_family_t happened to be char and not short, would be a zero-element array, resulting in a compile failure. BSD 4.3 didn't have an sa_len, while 4.4 did. in BSD 4.3 sa_family was a short, in 4.4 it was split up in 2 chars. Note that the RFC has 2 examples, one without sa_len, an other with sa_len. Kurt ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OSF build fixed
Kurt Roeckx [EMAIL PROTECTED] writes: Note that the RFC has 2 examples, one without sa_len, an other with sa_len. If you're talking about RFC 3493, the example with ss_len is flat wrong, since it fails to allow for the (strong) possibility that there will be a pad byte between ss_len and ss_family. This will typically result in making the struct alignof(int64) bigger than intended, since __ss_pad1 will be one byte too big, forcing __ss_align up to the next allowable alignment boundary. This is no doubt harmless, but there is little point in having such a complicated declaration if it fails to achieve its intended goal of exactly controlling the struct's size and alignment. BTW, where are we getting the SALEN macro from, and how are we sure that it tells the truth about whether the platform expects an ss_len field? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] OSF build fixed
On Tue, Jul 15, 2003 at 05:14:52PM -0400, Tom Lane wrote: BTW, where are we getting the SALEN macro from, and how are we sure that it tells the truth about whether the platform expects an ss_len field? I'm not sure, it was used before. Kurt ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] OSF build fixed
Kurt Roeckx [EMAIL PROTECTED] writes:
On Tue, Jul 15, 2003 at 05:14:52PM -0400, Tom Lane wrote:
BTW, where are we getting the SALEN macro from, and how are we sure
that it tells the truth about whether the platform expects an ss_len
field?
I'm not sure, it was used before.
Before when? A quick grep finds it nowhere in either the 7.2 or 7.3
trees ... which means we have zero field experience with it. My guess
is that someone threw it in and punted on making configure set it up.
In 7.3 and before, we never bother to set sin_len or sun_len as far as
I can see. Is it really necessary to start setting them now?
If we could dispense with the tests in the .c files, we could make a
much more robust definition of sockaddr_storage along the lines of
struct sockaddr_storage {
union {
struct sockaddr sa;
int64 __ss_align; /* ensure alignment */
char __ss_pad[128];/* ensure size */
} ss_stuff;
};
#define ss_family ss_stuff.sa.sa_family
Actually I'm inclined to do this even if we do need to set the length field;
but we'll need to add an honest configure test to see if it's there or not.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OSF build fixed
On Tue, Jul 15, 2003 at 05:37:39PM -0400, Tom Lane wrote:
I'm not sure, it was used before.
Before when? A quick grep finds it nowhere in either the 7.2 or 7.3
trees ... which means we have zero field experience with it. My guess
is that someone threw it in and punted on making configure set it up.
It was in CVS when I started working on my patch, so I assumed it
was checked somewhere.
In 7.3 and before, we never bother to set sin_len or sun_len as far as
I can see. Is it really necessary to start setting them now?
I don't know. It's probably set when you call getpeername() or
something. I doubt the kernel looks at it in other calls.
It's the other ipv6 patch that was applied that probably started
doing it, so I also did it.
If we could dispense with the tests in the .c files, we could make a
much more robust definition of sockaddr_storage along the lines of
struct sockaddr_storage {
union {
struct sockaddr sa;
int64 __ss_align; /* ensure alignment */
char __ss_pad[128];/* ensure size */
} ss_stuff;
};
#define ss_family ss_stuff.sa.sa_family
I'm not sure about that __ss_align one, I think you need 2 of
them.
Kurt
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OSF build fixed
Patches: int64-pqcomm.patch: changes int64_t to int64 in src/include/libpq/pqcomm.h tested on RedHat Linux 7.3 and OSF osf-template.patch: adds pthread support for OSF tested on OSF (uname -a: OSF1 hostname V4.0 1229 alpha) If these are okay, can someone apply them? Can someone with access to different OSF versions test pthread-safety as well? Regards, Philip Yarra.*** pgsql-old/src/include/libpq/pqcomm.h Wed Jun 25 10:42:16 2003 --- pgsql/src/include/libpq/pqcomm.h Mon Jul 7 17:30:11 2003 *** *** 38,44 * Desired design of maximum size and alignment */ #define _SS_MAXSIZE128 /* Implementation specific max size */ ! #define _SS_ALIGNSIZE (sizeof (int64_t)) /* Implementation specific desired alignment */ /* * Definitions used for sockaddr_storage structure paddings design. --- 38,44 * Desired design of maximum size and alignment */ #define _SS_MAXSIZE128 /* Implementation specific max size */ ! #define _SS_ALIGNSIZE (sizeof (int64)) /* Implementation specific desired alignment */ /* * Definitions used for sockaddr_storage structure paddings design. *** *** 61,67 /* 6 byte pad, this is to make implementation * specific pad up to alignment field that * follows explicit in the data structure */ ! int64_t __ss_align; /* field to force desired structure * storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; --- 61,67 /* 6 byte pad, this is to make implementation * specific pad up to alignment field that * follows explicit in the data structure */ ! int64 __ss_align; /* field to force desired structure * storage alignment */ char __ss_pad2[_SS_PAD2SIZE]; *** pgsql-old/src/template/osf Thu Sep 5 08:54:18 2002 --- pgsql/src/template/osf Mon Jul 7 17:30:59 2003 *** *** 4,6 --- 4,9 CC=$CC -std CFLAGS='-O4 -Olimit 2000' fi + SUPPORTS_THREADS=yes + THREAD_CFLAGS=-pthread + ---(end of broadcast)--- TIP 8: explain analyze is your friend
