Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)
On Mon, 10 Mar 2008, Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Tom Lane wrote: Applied with minor corrections. Why is this not the default when supported? Fear. Maybe eventually, but right now I think it's too risky. One point that I already found out the hard way is that sizeof(off_t) = 8 does not guarantee the availability of largefile support; there can also be filesystem-level constraints, and perhaps other things we know not of at this point. Just to note an additional filesystem that will need special action... The VxFS filesystem has a largefiles option, per filesystem. At least that was the case on SCO UnixWare (No, I no longer run it). LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [patch 0/9] annual pgcrypto update
Neil Conway wrote: > On Tue, 2006-07-11 at 15:57 -0400, Marko Kreen wrote: >> Few cleanups and couple of new things: >> >> - add SHA2 algorithm to older OpenSSL >> - add BIGNUM math to have public-key cryptography workon >> non-OpenSSL build. >> - gen_random_bytes() function > > I'll apply this shortly. > > To -patches, would folks prefer that I aggregate the patches into a > single CVS commit, or do a commit for each patch? > > -Neil Personal opinion, but since they are all related, one big commit seems to make sense to me. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] quick patch for pg_database.encoding doc
This patch adds a reference to the pg_encoding_to_char() function as a means to translate the number to something meaningful for a human. Index: doc/src/sgml/catalogs.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v retrieving revision 2.123 diff -c -r2.123 catalogs.sgml *** doc/src/sgml/catalogs.sgml 28 May 2006 02:27:08 - 2.123 --- doc/src/sgml/catalogs.sgml 2 Jun 2006 17:51:14 - *** *** 1954,1960 encoding int4 ! Character encoding for this database --- 1954,1962 encoding int4 ! Character encoding for this database. The ! pg_encoding_to_char can be used to translate ! this to the encoding name used -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893Index: doc/src/sgml/catalogs.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v retrieving revision 2.123 diff -c -r2.123 catalogs.sgml *** doc/src/sgml/catalogs.sgml 28 May 2006 02:27:08 - 2.123 --- doc/src/sgml/catalogs.sgml 2 Jun 2006 17:51:14 - *** *** 1954,1960 encoding int4 ! Character encoding for this database --- 1954,1962 encoding int4 ! Character encoding for this database. The ! pg_encoding_to_char can be used to translate ! this to the encoding name used ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] patch review, please: Autovacuum/Vacuum times via stats.
Larry Rosenman wrote: > Greetings, > I've got a patch to be reviewed for having the stats system keep > track of the last > time a table was vacuumed or analyzed either by the user or via > AutoVacuum. > > The patch is at: > http://www.lerctr.org/~ler/pg-dev/vacuum-autovacuum-times-stats.diff > > I'd appreciate a full review, it includes docs as well. > > Thanks! > > LER I just replaced this one with one that actually bumps catversion. LER pgsql-patches added as well. I think this one is applyable if the powers that be want to. Comments/criticism welcome. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Logging pg_autovacuum
Larry Rosenman wrote: > Jim C. Nasby wrote: >> On Mon, May 01, 2006 at 12:28:21PM -0500, Larry Rosenman wrote: >>> Since both vacuum and autovacuum will be cutting stats records, do >>> we want to just have the autovacuum >>> stats record have the fact that it was autovacuum that did the >>> vacuum? >>> >>> Or, is there a way when vacuum is run by autovacuum that I can get a >>> flag to set that says this (vacuum|analyze) was done by the >>> autovacuum daemon? >>> >>> I agree that the existing stats calls are good, but I'm still >>> reading code to see whether I can determine >>> at the time they are cut that this was autovacuum that did it. >> >> I think noting autovac vacuums/analyzes seperately is pg-dev/vacuum-time-patch-WIP.txt'nice-to-have' >> but not all that important. It'd probably be pretty easy to tell the >> difference just knowing what (if any) manual vacuums your system >> runs. >> >> While we're looking at logging, are you going to add stats stuff for >> the bgwriter as well, or should we add this to the TODO? > > I was going to do that after I got some comfort with what I'm doing > here. I've put a WIP patch up for comments: http://www.lerctr.org/~ler/pg-dev/vacuum-time-patch-WIP.txt this is *NOT* for application, as I still need to add access to the new fields to the views, etc. I'm looking to get comments on it. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 1: 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: [PATCHES] Reduce dependancies of postmaster (without --as-needed)
On Nov 28 2005, Tom Lane wrote: Larry Rosenman writes: >> -lnsl is needed on SVR4 derivatives, like Solaris and UnixWare. it is >> the network services library. > libsocket requires libnsl: > [1] NEEDED /usr/lib/libnsl.so.1 Hmmm ... but given that, is it needed to mention libnsl in the link command at all, or can the linker pick it up implicitly? I'm not 100% sure if the linker does the right thing or not :( It would be a good thing to test. I can make a shell account available (Tom, you actually have one on the box that output is from). LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Reduce dependancies of postmaster (without --as-needed)
On Nov 28 2005, Tom Lane wrote: Larry Rosenman writes: > -lnsl is needed on SVR4 derivatives, like Solaris and UnixWare. it is > the network services library. > You'll needed it for ANY socket based code on these platforms. Is there any specific function symbol we can test for in that library? If it exports something like socket() or connect() on SVR4, we can make configure probe for that instead of blindly including the library. libsocket requires libnsl: $ dump -Lv /usr/lib/libsocket.so|more /usr/lib/libsocket.so: DYNAMIC SECTION INFORMATION [INDEX] Tag Value .dynamic: [1] NEEDED /usr/lib/libnsl.so.1 [2] INIT0xba30 [3] SONAME /usr/lib/libsocket.so.2 [4] HASH0xa0 [5] STRTAB 0x22bc [6] SYMTAB 0x95c [7] STRSZ 0x1229 [8] SYMENT 0x10 [9] PLTGOT 0xec2c [10] PLTSZ 0x4b8 [11] PLTREL 0x11 [12] JMPREL 0x36d0 [13] REL 0x34e8 [14] RELSZ 0x1e8 . So, Is there a configure check for stuff like that? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Reduce dependancies of postmaster (without --as-needed)
On Nov 28 2005, Martijn van Oosterhout wrote: On Mon, Nov 28, 2005 at 10:18:08AM -0500, Tom Lane wrote: > Pulling those out is just not a good idea; we'd never have included them > in the first place if they weren't needed on some platforms. A lot of > these system libraries are very hard to test for in a reasonable way. > For instance, IIRC the reason libBSD is needed on HP-UX is that it > provides POSIX-compatible signal behavior. The same functions exist in > libc ... but they work differently :-( Yeah, but pulling them in when they're not needed is a waste also. I'm sure that a lot of platforms have -lnsl but I doubt many need it given it's for NIS/YP support. libBSD doesn't bother me as much because it's not going to exist on 99% of platforms. -lnsl is needed on SVR4 derivatives, like Solaris and UnixWare. it is the network services library. You'll needed it for ANY socket based code on these platforms. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Updated FAQ_SCO patch
This is an updated FAQ_SCO patch that inludes yesterday's changes, and also the float4/float8 issue I raised. Index: FAQ_SCO === RCS file: /projects/cvsroot/pgsql-server/doc/FAQ_SCO,v retrieving revision 1.9 diff -u -r1.9 FAQ_SCO --- FAQ_SCO 8 Nov 2002 16:49:15 - 1.9 +++ FAQ_SCO 15 May 2004 00:06:29 - @@ -9,7 +9,7 @@ original author:Andrew Merrill ([EMAIL PROTECTED]) -PostgreSQL 7.3 can be built on SCO UnixWare 7 and SCO OpenServer 5. +PostgreSQL 7.5 can be built on SCO UnixWare 7 and SCO OpenServer 5. On OpenServer, you can use either the OpenServer Development Kit or the Universal Development Kit. @@ -23,6 +23,8 @@ *) Compiling PostgreSQL using the UDK *) Reading the PostgreSQL man pages *) C99 Issues with the 7.1.1b Feature Supplement +*) --enable-thread-safety and UnixWare +*) float4/float8 regression failures on NaN and inf I/O. *** @@ -44,6 +46,8 @@ you install the correct version for your operating system, except as noted below. +Note: on UnixWare 7.1.3 and beyond, the GCC compiler is included on the UDK +CD as is GNUMake. *** *) GNU Make @@ -52,6 +56,9 @@ default, it installs as /usr/local/bin/make. To avoid confusion with the SCO make program, you may want to rename GNU make to gmake. +As of UnixWare 7.1.3 and above, the GNU Make program is is the OSTK portion +of the UDK CD, and is in /usr/gnu/bin/gmake. + *** *) Readline @@ -149,4 +156,28 @@ error in compiling tuplesort.c referencing inline functions. Apparently there was a change in the 7.1.2(8.0.0) compiler and beyond. + + +*** +*) --enable-thread-safety and UnixWare + +If you use the --enable-thread-safety configure flag, you *MUST* use -Kpthread +on ALL libpq using programs. + +libpq uses pthread_* calls, which are only available with the +-Kpthread/-Kthread flag. + +*** +*) float4/float8 regression failures on NaN and inf I/O. + +You will see regression failures for the float4 and float8 regression +tests on the NaN and inf I/O functions. This is due to a bug in SCO's strtod +library function on BOTH UnixWare and OpenServer. It's slated to be fixed +in the first maintenance / update for UnixWare 7.1.4, and probably the +next MP/UP for OpenServer 5.0.7 (I'm not sure on the OSR side as of the time +I'm writing this (2004-05-14). + +You might also see Join test failures due to ordering differences, and these +are ok. + -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 faq.patch Description: Binary data pgp0.pgp Description: PGP signature
[PATCHES] src/template/unixware syntax error
The following patch removes an extraneous "then" from src/template/unixware: Index: unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.36 diff -u -r1.36 unixware --- unixware13 May 2004 15:44:05 - 1.36 +++ unixware14 May 2004 15:36:45 - @@ -1,5 +1,4 @@ if test "$GCC" != yes; then -then # The -Kno_host is for a bug in the compiler. See -hackers # discussion on 7-8/Aug/2003. cat >conftest.c <<__EOF__ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749Index: unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.36 diff -u -r1.36 unixware --- unixware13 May 2004 15:44:05 - 1.36 +++ unixware14 May 2004 15:36:45 - @@ -1,5 +1,4 @@ if test "$GCC" != yes; then -then # The -Kno_host is for a bug in the compiler. See -hackers # discussion on 7-8/Aug/2003. cat >conftest.c <<__EOF__ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Friday, May 14, 2004 09:41:58 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: Reply from SCO: Indeed. For "inf", "infinity", and "nan", but not "nan(digits)", the pointer is left at the trailing matched character instead of the next. Moreover, checking our source history, it has been broken this way for nearly 12 years. Couldn't you folks have noticed this bug a little sooner!? :-) Doesn't give one a warm feeling for the average level of error checking in Unix programs, does it? nope I gather from this that it will be fixed in the first maint packs for 7.1.4. Good. I'd say we just leave it for that then. Ok, but see below. Is there some way we can work around this? I don't want to, because it would compromise the error checking. For instance, if we hack the code to accept this behavior, then it would also accept "NaNN" as soon as SCO fixes their bug. Won't this change behaviour for select 'NaN'::float8 etc such that Applications might fail? The regression tests exist to discover platform bugs as well as Postgres bugs. In this case, I think having them fail on unpatched SCO platforms is exactly what should happen. If you want, you can send in a docs patch for FAQ_SCO to give people a clue about it. OK. See above comment, etc. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 21:35:43 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: Where does it leave the "ptr" pointing to? $ ./test3 ptr=8049682, points to N ptr=8049686, points to f Indeed, they found an original new way to get it wrong. Please point out to them that the ptr is supposed to be advanced *past* the input. Not to the last character of the input. Reported to my SCO contacts. However, I guarantee this won't be fixed in 7.1.4 (the next release), as it just went Gold. Also, I suspect 7.1.3 and below have the bug, and are prevalent. And, I just proved it on my 7.1.2 (AKA OpenUNIX 8.0.0) system: $ cc -O -o test3 test3.c $ ./test3 num=nan errno=0 ptr=8049682, points to N num=inf errno=0 ptr=8049686, points to f $ uname -a OpenUNIX lerlsof 5 8.0.0 i386 x86at Caldera UNIX_SVR5 $ 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 21:26:50 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: I ran a quick C test: Where does it leave the "ptr" pointing to? $ cc -O -o test3 test3.c $ ./test3 num=nan errno=0 ptr=8049682, points to N num=inf errno=0 ptr=8049686, points to f $ cat test3.c #include #include #include int main(int argc,char **argv) { double num; char *input="NaN"; char *border1="/"; char *input2="inf"; char *border2="/"; char **ptr; num=strtod(input,ptr); printf("num=%g\n",num); printf("errno=%ld\n",errno); printf("ptr=%p, points to %s\n",*ptr,*ptr); num=strtod(input2,ptr); printf("num=%g\n",num); printf("errno=%ld\n",errno); printf("ptr=%p, points to %s\n",*ptr,*ptr); exit(0); } $ So, how's the easiest way to trace PG's float4in stuff? gdb is my favorite ... and (without installing it), how can I grab gdb on the gmake test backend(s)? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 21:14:40 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: Does Unixware support NaN/Infinity at all? Yes, we support NaN's and Inf. Hmph. Apparently their strtod() has thought of some original new way to misbehave on those inputs. Would you mind tracing through float4in() or float8in() to see exactly how it manages to fail? regards, tom lane I ran a quick C test: cc -O -o test3 test3.c $ ./test3 num=nan errno=0 $ cat test3.c #include #include #include int main(int argc,char **argv) { double num; char *input="NaN"; char **ptr; num=strtod(input,ptr); printf("num=%g\n",num); printf("errno=%ld\n",errno); exit(0); } So, how's the easiest way to trace PG's float4in stuff? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 20:49:28 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: the int4/int8 have to do with NaN and Infinity i/o. Those we care about. I was hoping CVS tip would Just Work Everywhere on that point, but evidently not :-(. What do you get? Did it work better in 7.4? Does Unixware support NaN/Infinity at all? regards, tom lane Yes, we support NaN's and Inf. From the fscanf manpage: When matching floating numbers, the locale's decimal point character is taken to introduce a fractional portion, the sequences inf and infinity (case ignored) are taken to represent infinities, and the sequence nan[(m)] (case ignored), where the optional parenthesized m consists of zero or more alphanumeric or underscore (_) characters, are taken to represent NaNs (not-a-numbers). Note, however, that the locale's thousands' separator character will not be recognized as such. I got: *** ./expected/float4.out Thu Mar 11 18:25:40 2004 --- ./results/float4.outThu May 13 19:08:18 2004 *** *** 33,67 ERROR: invalid input syntax for type real: "1235" -- special inputs SELECT 'NaN'::float4; ! float4 ! ! NaN ! (1 row) ! SELECT 'nan'::float4; ! float4 ! ! NaN ! (1 row) ! SELECT ' NAN '::float4; ! float4 ! ! NaN ! (1 row) ! SELECT 'infinity'::float4; ! float4 ! -- ! Infinity ! (1 row) ! SELECT ' -INFINiTY '::float4; ! float4 ! --- ! -Infinity ! (1 row) ! -- bad special inputs SELECT 'N A N'::float4; ERROR: invalid input syntax for type real: "N A N" --- 33,47 ERROR: invalid input syntax for type real: "1235" -- special inputs SELECT 'NaN'::float4; ! ERROR: invalid input syntax for type real: "NaN" SELECT 'nan'::float4; ! ERROR: invalid input syntax for type real: "nan" SELECT ' NAN '::float4; ! ERROR: invalid input syntax for type real: " NAN " SELECT 'infinity'::float4; ! ERROR: invalid input syntax for type real: "infinity" SELECT ' -INFINiTY '::float4; ! ERROR: invalid input syntax for type real: " -INFINiTY " -- bad special inputs SELECT 'N A N'::float4; ERROR: invalid input syntax for type real: "N A N" *** *** 70,88 SELECT ' INFINITYx'::float4; ERROR: invalid input syntax for type real: " INFINITYx" SELECT 'Infinity'::float4 + 100.0; ! ERROR: type "double precision" value out of range: overflow SELECT 'Infinity'::float4 / 'Infinity'::float4; ! ?column? ! -- ! NaN ! (1 row) ! SELECT 'nan'::float4 / 'nan'::float4; ! ?column? ! -- ! NaN ! (1 row) ! SELECT '' AS five, FLOAT4_TBL.*; five | f1 --+- --- 50,60 SELECT ' INFINITYx'::float4; ERROR: invalid input syntax for type real: " INFINITYx" SELECT 'Infinity'::float4 + 100.0; ! ERROR: invalid input syntax for type real: "Infinity" SELECT 'Infinity'::float4 / 'Infinity'::float4; ! ERROR: invalid input syntax for type real: "Infinity" SELECT 'nan'::float4 / 'nan'::float4; ! ERROR: invalid input syntax for type real: "nan" SELECT '' AS five, FLOAT4_TBL.*; five | f1 --+- == *** ./expected/float8.out Fri Apr 23 15:32:20 2004 --- ./results/float8.out Thu May 13 19:08:18 2004 *** *** 33,67 ERROR: invalid input syntax for type double precision: "123 5" -- special inputs SELECT 'NaN'::float8; ! float8 ! ! NaN ! (1 row) ! SELECT 'nan'::float8; ! float8 ! ! NaN ! (1 row) ! SELECT ' NAN '::float8; ! float8 ! ! NaN ! (1 row) ! SELECT 'infinity'::float8; ! float8 ! -- ! Infinity ! (1 row) ! SELECT ' -INFINiTY '::float8; ! float8 ! --- ! -Infinity ! (1 row) ! -- bad special inputs SELECT 'N A N'::float8; ERROR: invalid input syntax for type double precision: "N A N" --- 33,47 ERROR: invalid input syntax for type double precision: "123 5" -- special inputs SELECT 'NaN'::float8; ! ERROR: invalid input syntax for type double precision: "NaN" SELECT 'nan'::float8; ! ERROR: invalid input syntax for type double precision: "nan" SELECT ' NAN '::float8; ! ERROR: invalid input syntax for type double precision: " NAN "
[PATCHES] FAQ_SCO update for --enable-thread-safety and some other stuff
$ cvs diff -u FAQ_SCO Index: FAQ_SCO === RCS file: /projects/cvsroot/pgsql-server/doc/FAQ_SCO,v retrieving revision 1.9 diff -u -r1.9 FAQ_SCO --- FAQ_SCO 8 Nov 2002 16:49:15 - 1.9 +++ FAQ_SCO 14 May 2004 00:23:35 - @@ -9,7 +9,7 @@ original author:Andrew Merrill ([EMAIL PROTECTED]) -PostgreSQL 7.3 can be built on SCO UnixWare 7 and SCO OpenServer 5. +PostgreSQL 7.5 can be built on SCO UnixWare 7 and SCO OpenServer 5. On OpenServer, you can use either the OpenServer Development Kit or the Universal Development Kit. @@ -23,6 +23,7 @@ *) Compiling PostgreSQL using the UDK *) Reading the PostgreSQL man pages *) C99 Issues with the 7.1.1b Feature Supplement +*) --enable-thread-safety and UnixWare *** @@ -44,6 +45,8 @@ you install the correct version for your operating system, except as noted below. +Note: on UnixWare 7.1.3 and beyond, the GCC compiler is included on the UDK +CD as is GNUMake. *** *) GNU Make @@ -52,6 +55,9 @@ default, it installs as /usr/local/bin/make. To avoid confusion with the SCO make program, you may want to rename GNU make to gmake. +As of UnixWare 7.1.3 and above, the GNU Make program is is the OSTK portion +of the UDK CD, and is in /usr/gnu/bin/gmake. + *** *) Readline @@ -149,4 +155,15 @@ error in compiling tuplesort.c referencing inline functions. Apparently there was a change in the 7.1.2(8.0.0) compiler and beyond. + + +*** +*) --enable-thread-safety and UnixWare + +If you use the --enable-thread-safety configure flag, you *MUST* use -Kpthread +on ALL libpq using programs. + +libpq uses pthread_* calls, which are only available with the +-Kpthread/-Kthread flag. + $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 faq.patch Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 20:11:45 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Good. I changed my commit to use your version. Thanks! Do we care about regression failures at this stage? I have int4/int8/join failures (join is not new, and is an order issue). the int4/int8 have to do with NaN and Infinity i/o. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 20:03:24 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: > So we just add the thing in the template file? Yea, I can do that. I > did it there because Win32 already had something for libs. Does the > template file get included in Makefile.global? I didn't think so. Not the template, the port-specific makefile. Oh, I forgot about those. Done. I did this patch, and it works: $ cvs diff -u Makefile.unixware Index: Makefile.unixware === RCS file: /projects/cvsroot/pgsql-server/src/makefiles/Makefile.unixware,v retrieving revision 1.17 diff -u -r1.17 Makefile.unixware --- Makefile.unixware 5 Jan 2003 13:45:47 - 1.17 +++ Makefile.unixware 14 May 2004 00:06:07 - @@ -25,6 +25,7 @@ else SO_FLAGS = -G endif +CFLAGS += $(PTHREAD_CFLAGS) %.so: %.o $(CC) $(SO_FLAGS) -o $@ $< $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 19:46:00 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: *** src/Makefile.global.in 11 May 2004 21:57:14 - 1.182 --- src/Makefile.global.in 13 May 2004 23:03:12 - *** *** 177,182 --- 177,188 CFLAGS += -Wall -Wmissing-prototypes -Wmissing-declarations endif + # Unixware needs threads for everything that uses libpq + ifeq ($(PORTNAME),unixware) + CFLAGS += "$PTHREAD_CFLAGS" + endif + + # Kind-of compilers YACC = @YACC@ Yech. Isn't this what the Makefile.port files are for? Makefile.global should never contain any "#ifdef port" junk. regards, tom lane It also appears from testing, that this does NOT fix the initdb issue. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 19:06:15 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: Larry Rosenman wrote: > Really? You are configuring with --enable-thread-safety? I just > updated your template in CVS, and it is attached. However, any old CVS > should work fine. Nope, initdb is where we still die: Patch applied: Force thread flags for all Unixware builds if threading is requested. This is required because once you link with a library that uses threads, all references to that library have to use thread flags. I manually added that patch, and re-did configure, et al from a gmake maintainer-clean, and we still die at initdb: cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport -o initdb Undefined first referenced symbol in file pthread_mutex_unlocklibpq.so pthread_getspecific libpq.so pthread_mutex_lock libpq.so pthread_key_create libpq.so pthread_oncelibpq.so pthread_setspecific libpq.so UX:ld: ERROR: Symbol referencing errors. No output written to initdb gmake[3]: *** [initdb] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src' gmake: *** [all] Error 2 [1] + Done(2) gmake >gmake.out 2>&1 & $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
On Fri, 19 Mar 2004, Bruce Momjian wrote: > Larry Rosenman wrote: > > > Yes, his patch ended up adding this to THREAD_LIBS, but > > > template/unixware has: > > > > > > For gcc: > > > > > > THREAD_CPPFLAGS="-pthread" > > > > > > and for non-gcc: > > > > > > THREAD_CPPFLAGS="-K pthread" > > > > > > Larry, are these wrong? > > > > Nope, those work, and should be passed to any libpq-using programs > > link step if --enable-thread-safety is used. > > But they currently CPPFLAGS. They should be lib flags. > > they need to be passed to BOTH compiles and Links. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
On Fri, 19 Mar 2004, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Tom Lane wrote: > > >> It seems that what we have to do for Unixware is add > > >> -Kpthread to LDFLAGS; is that correct? > > > > > Unusually, this platform doesn't have a THREAD_LIBS setting, only > > > THREAD_CPPFLAGS. so I have to use that. > > > > If Larry quoted the Compiler Guys correctly, then that is *wrong*, > > and we should put -Kpthread into THREAD_LIBS. > > Yes, his patch ended up adding this to THREAD_LIBS, but > template/unixware has: > > For gcc: > > THREAD_CPPFLAGS="-pthread" > > and for non-gcc: > > THREAD_CPPFLAGS="-K pthread" > > Larry, are these wrong? Nope, those work, and should be passed to any libpq-using programs link step if --enable-thread-safety is used. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
--On Friday, March 19, 2004 09:18:03 -0600 Larry Rosenman <[EMAIL PROTECTED]> wrote: --On Friday, March 19, 2004 10:15:56 -0500 Bruce Momjian <[EMAIL PROTECTED]> wrote: [moved to -patches because of the patch] --On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian <[EMAIL PROTECTED]> wrote: > Larry Rosenman wrote: >> > I thought that once you include libpthread in libpq, that you don't >> > have to mention it again then you use libpq. Is your platform >> > different somehow in this regard? >> > >> > I seem to remember this problem with libcrypt and libpq. Is this >> > the same problem? >> > >> > I see that initdb is just the first of many /bin programs to be >> > compiled, so if we have to add the thread lib, we will have to do >> > it for all the bin programs. Yikes. Why wasn't this a problem for >> > 7.4? >> 7.4 had initdb as a Shell Script. >> the 7.4.x libpq didn't have any pthread_* references in it, that I >> see on my box. > > Ah, yes. We added the thread-local storage to handle SIGPIPE. The > problem is that initdb isn't the only place. If you comment out > initdb from the Makefile in src/bin, does the next make fail too? I > bet it does. Apparently, because of the way the wrappers work, having -lpthread on libpq.so does NOT add it to the NEEDED list. I made the following patch, and all compiles now: Yes, I was afraid of that. Is there any way to make it work? If not, evey libpq program you create will need -lpthread added. I think we need to mention if you --enable-thread-safety you MUST use -lpthread on UnixWare, at least. I don't know about other platforms. I'll ask the compiler guys, but I suspect we're going to have to do it this way. From the Compiler Guys: The a.out (not any library) should be linked with -Kpthread (not -lpthread). This will force libthread to be linked in the right order relative to libc, libC, networking libraries, etc. In other words, the entire application either is or is not linked with threads; it's not a property of an individual library. SO, IF we are using the threads flags, we need to use them on ALL libpq-using programs, ours or the users. Not surprising. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
[moved to -patches because of the patch] --On Friday, March 19, 2004 08:01:53 -0500 Bruce Momjian <[EMAIL PROTECTED]> wrote: Larry Rosenman wrote: > I thought that once you include libpthread in libpq, that you don't > have to mention it again then you use libpq. Is your platform > different somehow in this regard? > > I seem to remember this problem with libcrypt and libpq. Is this the > same problem? > > I see that initdb is just the first of many /bin programs to be > compiled, so if we have to add the thread lib, we will have to do it > for all the bin programs. Yikes. Why wasn't this a problem for 7.4? 7.4 had initdb as a Shell Script. the 7.4.x libpq didn't have any pthread_* references in it, that I see on my box. Ah, yes. We added the thread-local storage to handle SIGPIPE. The problem is that initdb isn't the only place. If you comment out initdb from the Makefile in src/bin, does the next make fail too? I bet it does. Apparently, because of the way the wrappers work, having -lpthread on libpq.so does NOT add it to the NEEDED list. I made the following patch, and all compiles now: Index: src/bin/initdb/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/bin/initdb/Makefile,v retrieving revision 1.35 diff -u -r1.35 Makefile --- src/bin/initdb/Makefile 23 Dec 2003 21:56:20 - 1.35 +++ src/bin/initdb/Makefile 19 Mar 2004 13:35:19 - @@ -20,7 +20,7 @@ all: submake-libpq submake-libpgport initdb initdb: $(OBJS) $(libpq_builddir)/libpq.a - $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@ + $(CC) $(CFLAGS) $(OBJS) $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@ install: all installdirs $(INSTALL_PROGRAM) initdb$(X) $(DESTDIR)$(bindir)/initdb$(X) Index: src/bin/pg_dump/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/Makefile,v retrieving revision 1.44 diff -u -r1.44 Makefile --- src/bin/pg_dump/Makefile 7 Feb 2004 07:20:12 - 1.44 +++ src/bin/pg_dump/Makefile 19 Mar 2004 13:35:19 - @@ -25,13 +25,13 @@ all: submake-libpq submake-libpgport submake-backend pg_dump pg_restore pg_dumpall pg_dump: pg_dump.o common.o pg_dump_sort.o $(OBJS) $(libpq_builddir)/libpq.a - $(CC) $(CFLAGS) pg_dump.o common.o pg_dump_sort.o $(OBJS) $(EXTRA_OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@ + $(CC) $(CFLAGS) pg_dump.o common.o pg_dump_sort.o $(OBJS) $(EXTRA_OBJS) $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@ pg_restore: pg_restore.o $(OBJS) $(libpq_builddir)/libpq.a - $(CC) $(CFLAGS) pg_restore.o $(OBJS) $(EXTRA_OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@ + $(CC) $(CFLAGS) pg_restore.o $(OBJS) $(EXTRA_OBJS) $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@ pg_dumpall: pg_dumpall.o dumputils.o $(libpq_builddir)/libpq.a - $(CC) $(CFLAGS) pg_dumpall.o dumputils.o $(EXTRA_OBJS) $(libpq) $(LDFLAGS) $(LIBS) -o $@ + $(CC) $(CFLAGS) pg_dumpall.o dumputils.o $(EXTRA_OBJS) $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@ .PHONY: submake-backend submake-backend: Index: src/bin/pg_encoding/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_encoding/Makefile,v retrieving revision 1.16 diff -u -r1.16 Makefile --- src/bin/pg_encoding/Makefile29 Nov 2003 19:52:05 - 1.16 +++ src/bin/pg_encoding/Makefile19 Mar 2004 13:35:19 - @@ -17,7 +17,7 @@ all: submake-libpq submake-libpgport pg_encoding pg_encoding: $(OBJS) - $(CC) $(CFLAGS) $^ $(libpq) $(LDFLAGS) $(LIBS) -o $@ + $(CC) $(CFLAGS) $^ $(libpq) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@ install: all installdirs $(INSTALL_PROGRAM) pg_encoding$(X) $(DESTDIR)$(bindir)/pg_encoding$(X) Index: src/bin/pgtclsh/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/bin/pgtclsh/Makefile,v retrieving revision 1.43 diff -u -r1.43 Makefile --- src/bin/pgtclsh/Makefile19 Dec 2003 11:54:25 - 1.43 +++ src/bin/pgtclsh/Makefile19 Mar 2004 13:35:20 - @@ -33,10 +33,10 @@ all: submake $(PROGRAMS) pgtclsh: pgtclAppInit.o - $(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TCL_LIB_SPEC) $(TCL_LIBS) $(LDFLAGS) $(LIBS) -o $@ + $(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TCL_LIB_SPEC) $(TCL_LIBS) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@ pgtksh: pgtkAppInit.o - $(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TK_LIB_SPEC) $(TK_LIBS) $(TCL_LIB_SPEC) $(LDFLAGS) $(LIBS) -o $@ + $(CC) $(CFLAGS) $^ $(libpgtcl) $(libpq) $(TK_LIB_SPEC) $(TK_LIBS) $(TCL_LIB_SPEC) $(LDFLAGS) $(LIBS) $(THREAD_LIBS) -o $@ .PHONY: submake submake: Index: src/bin/psql/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/Makefile,v retrieving revision 1.40 diff -u -r1.40 Makefile --- src/bin/psql/Mak
[PATCHES] UnixWare Thread Patch (and test_fsync)
Here is a patch for the UnixWare thread stuff (template only, not initdb), and to the test_fsync makefile to remove a gcc'ism: Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.30 diff -u -r1.30 unixware --- src/template/unixware 11 Feb 2004 21:44:06 - 1.30 +++ src/template/unixware 18 Mar 2004 21:39:25 - @@ -24,5 +24,9 @@ THREAD_CPPFLAGS="-K pthread" fi -# tools/thread/thread_test must be run +THREAD_SUPPORT=yes THREAD_CPPFLAGS="$THREAD_CPPFLAGS -D_REENTRANT" +STRERROR_THREADSAFE=yes +GETPWUID_THREADSAFE=yes +GETHOSTBYNAME_THREADSAFE=yes + Index: src/tools/fsync/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/tools/fsync/Makefile,v retrieving revision 1.1 diff -u -r1.1 Makefile --- src/tools/fsync/Makefile18 Mar 2004 03:56:59 - 1.1 +++ src/tools/fsync/Makefile18 Mar 2004 21:39:26 - @@ -4,7 +4,7 @@ # TARGET = test_fsync XFLAGS = -CFLAGS = -g -Wall +CFLAGS = -O LIBS = $(TARGET) : test_fsync.o -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pg-tip.patch1 Description: Binary data pgp0.pgp Description: PGP signature
Re: [PATCHES] Problem with dblink
On Wed, 26 Nov 2003, Joe Conway wrote: > Tom Lane wrote: > > Yeah, I think to apply it to a stable branch you'd want some indication > > that there are more live bugs out there that it's needed to catch. At > > the moment it only seems called for as an aid to future development, and > > so HEAD seems sufficient. > > > > Thanks, that's what i thought. > > On a loosely related question, I didn't see commit messages for my > commits. Am I supposed to do something specific to cause them to be emitted? I did see them (although you ought to get Marc to change the Real Name field to show Joe Conway instead of User joe). LER > > Joe > > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Problem with dblink
On Wed, 26 Nov 2003, Joe Conway wrote: > Christopher Kings-Lynne wrote: > > I saw them, "User Joe" :) > > > > Yeah, they just showed up for me too. I'll have to figure out how to > change that from "User Joe" to something else -- sounds kind of strange ;-) Does Marc allow chfn to run on those boxes? If so, run it. :-) LER > > Joe > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] UW 713UP3 patch
--On Wednesday, November 05, 2003 04:23:35 -0500 Bruce Momjian <[EMAIL PROTECTED]> wrote: Peter Eisentraut wrote: Larry Rosenman writes: > You can reduce the example down to > >extern char *strcpy(char *, const char *); > >static void f(char *p, int n){ > strcpy(p+n,""); >} >void g(void){ > f(0, 0); >} > > compile with cc -O -Kinline I've installed a test based on this and checked off UnixWare on the supported platforms list. Another idea would have been to just grep the include file for the version define. :-) It's not in an include, it's done automagiclly by the compiler. LER -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] UW 713UP3 patch
--On Monday, November 03, 2003 23:24:19 +0100 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: > I'll try and write the patch as you suggest. Here's a patch as you suggested: Isn't there a way to write a test that actually triggers the bug we're trying to work around? Here is what the SCO Folks said when I reported this back in August: You can reduce the example down to extern char *strcpy(char *, const char *); static void f(char *p, int n){ strcpy(p+n,""); } void g(void){ f(0, 0); } compile with cc -O -Kinline that will trip it. I still think that using the __SCO_VERSION__ preprocessor symbol is the better idea. -- Peter Eisentraut [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] UW 713UP3 patch
--On Monday, November 03, 2003 23:24:19 +0100 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: > I'll try and write the patch as you suggest. Here's a patch as you suggested: Isn't there a way to write a test that actually triggers the bug we're trying to work around? Not that I'm aware of (it was the following entry from SCO's fix list: 141. A bug was repaired in which an inlined function call, having been passed a null pointer, would trigger an internal C compiler error when this parameter was the target of a strcpy() or strncpy() call. fz528141 If you want to write a test, fine, but I think I've done my part which is report the bug to SCO, get a fix released, and then change our stuff to detect it. See the discussion referenced in the template file (7-8/AUG/2003 on -Hackers). -- Peter Eisentraut [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] UW 713UP3 patch
--On Sunday, November 02, 2003 17:23:59 -0600 Larry Rosenman <[EMAIL PROTECTED]> wrote: --On Sunday, November 02, 2003 18:17:26 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: +# version check for the 7.1.3UP3 compiler (version 401200310): +cat >conftest.c <<__EOF__ +int main(int argc, char **argv) +#if __SCO_VERSION__ >=3D 401200310 +#error good compiler +#else +#error bad compiler +#endif +__EOF__ + $CC conftest.c 2>conftest.err 1>&2 + grep -q good conftest.err + if test $? =3D 0; then +CFLAGS=3D"-O -Kinline" + else +CFLAGS=3D"-O -Kinline,no_host" + fi Couldn't this be simplified to +cat >conftest.c <<__EOF__ +int main(int argc, char **argv) +{ +#if __SCO_VERSION__ < 401200310 +#error bad compiler +#endif +} +__EOF__ + $CC conftest.c >/dev/null 2>&1 + if test $? = 0; then +CFLAGS="-O -Kinline" + else +CFLAGS="-O -Kinline,no_host" + fi regards, tom lane How about this? ( I needed to make it valid C): OOOPPPSS. Yes, Tom, yours will work just fine. I missed the fact that you put the #if inside the braces. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] UW 713UP3 patch
--On Sunday, November 02, 2003 18:17:26 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: +# version check for the 7.1.3UP3 compiler (version 401200310): +cat >conftest.c <<__EOF__ +int main(int argc, char **argv) +#if __SCO_VERSION__ >=3D 401200310 +#error good compiler +#else +#error bad compiler +#endif +__EOF__ + $CC conftest.c 2>conftest.err 1>&2 + grep -q good conftest.err + if test $? =3D 0; then +CFLAGS=3D"-O -Kinline" + else +CFLAGS=3D"-O -Kinline,no_host" + fi Couldn't this be simplified to +cat >conftest.c <<__EOF__ +int main(int argc, char **argv) +{ +#if __SCO_VERSION__ < 401200310 +#error bad compiler +#endif +} +__EOF__ + $CC conftest.c >/dev/null 2>&1 + if test $? = 0; then +CFLAGS="-O -Kinline" + else +CFLAGS="-O -Kinline,no_host" + fi regards, tom lane How about this? ( I needed to make it valid C): Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.27 diff -u -r1.27 unixware --- src/template/unixware 25 Oct 2003 15:32:11 - 1.27 +++ src/template/unixware 2 Nov 2003 23:22:21 - @@ -1,13 +1,27 @@ if test "$GCC" = yes; then THREAD_CPPFLAGS="-pthread" else -# the -Kno_host is temporary for a bug in the compiler. See -hackers +# the -Kno_host is for a bug in the compiler. See -hackers # discussion on 7-8/Aug/2003. -# when the 7.1.3UP3 or later compiler is out, we can do a version check. - CFLAGS="-O -Kinline,no_host" +# version check for the 7.1.3UP3 compiler (version 401200310): +cat >conftest.c <<__EOF__ +#if __SCO_VERSION__ < 401200310 +#error bad compiler +#endif +int main(int argc,char **argv) +{ +} + +__EOF__ + $CC conftest.c >/dev/null 2>&1 + if test $? = 0; then +CFLAGS="-O -Kinline" + else +CFLAGS="-O -Kinline,no_host" + fi + rm conftest.* THREAD_CPPFLAGS="-K pthread" fi - THREAD_SUPPORT=yes NEED_REENTRANT_FUNCS=no # verified 7.1.3 2003-09-03 THREAD_CPPFLAGS="$THREAD_CPPFLAGS -D_REENTRANT" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 unixware.up3.patch3 Description: Binary data pgp0.pgp Description: PGP signature
Re: [PATCHES] UW 713UP3 patch
--On Sunday, November 02, 2003 15:29:37 -0600 Larry Rosenman <[EMAIL PROTECTED]> wrote: I'll try and write the patch as you suggest. Here's a patch as you suggested: Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.27 diff -u -r1.27 unixware --- src/template/unixware 25 Oct 2003 15:32:11 - 1.27 +++ src/template/unixware 2 Nov 2003 21:53:33 - @@ -1,13 +1,27 @@ if test "$GCC" = yes; then THREAD_CPPFLAGS="-pthread" else -# the -Kno_host is temporary for a bug in the compiler. See -hackers +# the -Kno_host is for a bug in the compiler. See -hackers # discussion on 7-8/Aug/2003. -# when the 7.1.3UP3 or later compiler is out, we can do a version check. - CFLAGS="-O -Kinline,no_host" +# version check for the 7.1.3UP3 compiler (version 401200310): +cat >conftest.c <<__EOF__ +int main(int argc, char **argv) +#if __SCO_VERSION__ >= 401200310 +#error good compiler +#else +#error bad compiler +#endif +__EOF__ + $CC conftest.c 2>conftest.err 1>&2 + grep -q good conftest.err + if test $? = 0; then +CFLAGS="-O -Kinline" + else +CFLAGS="-O -Kinline,no_host" + fi + rm conftest.* THREAD_CPPFLAGS="-K pthread" fi - THREAD_SUPPORT=yes NEED_REENTRANT_FUNCS=no # verified 7.1.3 2003-09-03 THREAD_CPPFLAGS="$THREAD_CPPFLAGS -D_REENTRANT" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 unixware.up3.patch2 Description: Binary data pgp0.pgp Description: PGP signature
Re: [PATCHES] UW 713UP3 patch
--On Sunday, November 02, 2003 23:05:21 +0100 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: The problem is MOST people will **NOT** be able to get the fixed compiler as it's on the Upgrade Pack path (PAY FOR), and **NOT** the Maintenance Pack path (Free). Why did they upgrade to the broken compiler in the first place, and why doesn't SCO provide free fixes for broken products? The "Broken Compiler" is in EVERY version prior to the UP3 compiler. We just started tripping it with the changes in 7.4. I don't know why they didn't/haven't put this fix in the MP path, and I can't change that decision, therefore, we need to work around it. It's not that big of a deal. See the patch I posted that SHOULD meet your requirements. -- Peter Eisentraut [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] UW 713UP3 patch
--On Sunday, November 02, 2003 22:26:40 +0100 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: Since peter objects to my methods, what is an ACCEPTABLE way to detect the 7.1.3UP3 compiler? One POSSIBLE way to do this properly is to write a test that 1) Uses $CC, $CFLAGS, and related variables rather than hardcoding 'cc -O'. 2) Names any test files conftest.*, so configure cleans up automatically. 3) Doesn't execute any compiled programs. See the __FAST_MATH__ test for an example. However, I still think that we should not bother testing for this. Considering that the condition first occurred a couple of months ago and is already fixed, this isn't a big issue. Think about what would happen if we had to develop and maintain fixes for every buggy GCC compiler every released. The problem is MOST people will **NOT** be able to get the fixed compiler as it's on the Upgrade Pack path (PAY FOR), and **NOT** the Maintenance Pack path (Free). I'll try and write the patch as you suggest. -- Peter Eisentraut [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[PATCHES] UW 713UP3 patch
Since peter objects to my methods, what is an ACCEPTABLE way to detect the 7.1.3UP3 compiler? I'd like to get this fixed for RC1. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] UnixWare UP3 compiler detection patch
--On Saturday, November 01, 2003 00:17:46 +0100 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: I put the following patch to detect the 7.1.3 UP3 compiler. If there are no SERIOUS objections, please apply: This patch breaks about all the rules for robust autoconf tests: 1. Compile things using the compiler and the flags that the user chose, not hardcoded ones. We are just checking a preprocessor define that we know will exist in the SCO cc case, and this preprocessor define does NOT change based on flags. 2. Make sure you can clean up after yourself even if your code doesn't run all the way through. I can, and I've tested it, because I blew the test a couple of times. 3. Don't execute programs you just compiled. Why not? It's only on the ONE platform, and how would you prefer the test be done? -- Peter Eisentraut [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[PATCHES] UnixWare UP3 compiler detection patch
I put the following patch to detect the 7.1.3 UP3 compiler. If there are no SERIOUS objections, please apply: Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.27 diff -u -r1.27 unixware --- src/template/unixware 25 Oct 2003 15:32:11 - 1.27 +++ src/template/unixware 31 Oct 2003 15:37:23 - @@ -1,13 +1,28 @@ if test "$GCC" = yes; then THREAD_CPPFLAGS="-pthread" else -# the -Kno_host is temporary for a bug in the compiler. See -hackers +# the -Kno_host is for a bug in the compiler. See -hackers # discussion on 7-8/Aug/2003. -# when the 7.1.3UP3 or later compiler is out, we can do a version check. - CFLAGS="-O -Kinline,no_host" +# version check for the 7.1.3UP3 compiler (version 401200310): +cat >testcompver.c <<__EOF__ +#include +#include +int main(int argc, char **argv) +{ + if (__SCO_VERSION__ >= 401200310) exit(1); + else exit(0); +} +__EOF__ + cc -O -o testcompver testcompver.c + ./testcompver + if test $? = 1; then +CFLAGS="-O -Kinline" + else +CFLAGS="-O -Kinline,no_host" + fi + rm testcompver testcompver.c THREAD_CPPFLAGS="-K pthread" fi - THREAD_SUPPORT=yes NEED_REENTRANT_FUNCS=no # verified 7.1.3 2003-09-03 THREAD_CPPFLAGS="$THREAD_CPPFLAGS -D_REENTRANT" -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 unixware.up3.patch Description: Binary data pgp0.pgp Description: PGP signature
Re: [HACKERS] [PATCHES] Reorganization of spinlock defines
--On Thursday, September 11, 2003 23:13:54 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all= =20 care). Unfixably? Or just a small oversight? I'm actually not worried about platforms that are actively being tested. It's the stuff that hasn't been confirmed recently that is going to be at risk. I'm seeing failures with the 2nd patch as well. Seems like it's not liking UnixWare's cc defines. the documentation is at: http://www.lerctr.org:8458/ the cc man page is at: http://www.lerctr.org:8458/en/man/html.1/cc.1.html Tom, You still have an account here. Bruce, if you'd like an account, that is easily arranged. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] [PATCHES] Reorganization of spinlock defines
--On Friday, September 12, 2003 00:00:43 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: Please, only the first two. Make the Unixware template add __i386__. Don't add assumptions about valid user-namespace symbols. that's reasonable. At least until 64-bit UnixWare. :-) Even then, I'd prefer to put the necessary kluge into template/unixware or Makefile.unixware or port/unixware.h, rather than add a risky assumption globally. Sure, and 64-bit UnixWare is 2 years out any way. Hopefully we can get reasonableness by then. I've already sent a whine-a-gram to the compiler guys at SCO. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] [PATCHES] Reorganization of spinlock defines
--On Friday, September 12, 2003 00:06:49 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Larry Rosenman <[EMAIL PROTECTED]> writes: I've already sent a whine-a-gram to the compiler guys at SCO. Prolly you thought of this already, but: getting them to *add* an implicit #define of __i386__ should be plenty easy compared to getting them to *remove* the one for i386. And while I think they should remove the latter, the immediate problem would be solved as soon as they add the former. sure, and I expect that's what they may do. We'll see what they say. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] [PATCHES] Reorganization of spinlock defines
--On Thursday, September 11, 2003 23:42:53 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: Looking at the code, I wonder if we already have folks not using spinlocks, and not even knowing it. I don't think problem reports will be limited to new platforms. Very likely --- I heard from someone recently who was trying to run HPUX/Itanium. After we got past the hard-wired assumption that HPUX == HPPA, it was still giving lousy performance for lack of spinlocks. I like the part of the patch that is in-your-face about that. I just learned from Larry that Unixware defines intel as i386, not __i386 or __i386__, at least of the native SCO compiler that he uses. [blink] Namespace infringement 'r us, huh? Yeah. I **DO** have SCO's ear on it, but I don't know how far I'll get, plus there are TONS of pre-whenever-we-get-it-fixed out there. I am going to test for __cpu, __cpu__, and cpu on non-gcc compiler for consistency. It is only done in one place in the patch, so that should be good. Please, only the first two. Make the Unixware template add __i386__. Don't add assumptions about valid user-namespace symbols. that's reasonable. At least until 64-bit UnixWare. :-) (announced at SCOForum). regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] Reorganization of spinlock defines
--On Thursday, September 11, 2003 23:46:56 -0300 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: On Thu, 11 Sep 2003, Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: > The problem with waiting for 7.5 is that we will have no error > reporting when our non-spinlock code is being executed, and with > Opteron/Itanium, it seems like a good time to get it working. Well, as long as you're prepared to reduce the list of known supported platforms to zero as of 7.4beta3, and issue a fresh call for port reports. I didn't think we had done that yet ... had we? called for port reports, that is ... ? But it seems to me that this is mostly a cosmetic cleanup and therefore not the kind of thing to be doing late in beta. Couldn't we do something that affects only Opteron/Itanium and doesn't take a chance on breaking everything else? I just went through the whole patch myself, and as much as I like the overall simplification, I tend to agree with Tom here on questioning the requirement to do suck a massive change so late in the end cycle ... is there no smaller bandaid that can be applied to handle the Opteron/Itanium issue for v7.4, with the "cleanup patch" being applied right away after v7.4? Bruce sent me a copy of the patch, and it BREAKS UnixWare (If y'all care). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] Unixware 713 probs
--On Sunday, September 07, 2003 14:19:00 -0500 Larry Rosenman <[EMAIL PROTECTED]> wrote: --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote: [snip] /usr/local/bin/gmake -C libpq all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq' cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o ip.o ip.c UX:acomp: ERROR: "ip.c", line 416: Syntax error before or at: . UX:acomp: WARNING: "ip.c", line 419: left operand of "." must be struct/union object UX:acomp: WARNING: "ip.c", line 427: left operand of "." must be struct/union object UX:acomp: WARNING: "ip.c", line 428: left operand of "." must be struct/union object UX:acomp: WARNING: "ip.c", line 429: left operand of "." must be struct/union object UX:acomp: WARNING: "ip.c", line 430: left operand of "." must be struct/union object UX:acomp: ERROR: "ip.c", line 451: Syntax error before or at: . UX:acomp: ERROR: "ip.c", line 452: invalid type combination UX:acomp: WARNING: "ip.c", line 455: left operand of "." must be struct/union object UX:acomp: WARNING: "ip.c", line 464: left operand of "." must be struct/union object UX:acomp: WARNING: "ip.c", line 465: left operand of "." must be struct/union object UX:acomp: WARNING: "ip.c", line 466: left operand of "." must be struct/union object UX:acomp: line 416 is: int32 s_addr; s_addr is seen by the compiler as: uint32 __S_un . __S_addr ; We need to pick another name. LER Here's a quickie patch I did to fix it. Index: src/backend/libpq/ip.c === RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/ip.c,v retrieving revision 1.21 diff -u -r1.21 ip.c --- src/backend/libpq/ip.c 5 Sep 2003 23:07:21 - 1.21 +++ src/backend/libpq/ip.c 7 Sep 2003 19:36:06 - @@ -413,10 +413,10 @@ { struct sockaddr_in addr4; struct sockaddr_in6 addr6; - uint32 s_addr; + uint32 pg_s_addr; memcpy(&addr4, addr, sizeof(addr4)); - s_addr = ntohl(addr4.sin_addr.s_addr); + pg_s_addr = ntohl(addr4.sin_addr.s_addr); memset(&addr6, 0, sizeof(addr6)); @@ -424,10 +424,10 @@ addr6.sin6_addr.s6_addr[10] = 0xff; addr6.sin6_addr.s6_addr[11] = 0xff; - addr6.sin6_addr.s6_addr[12] = (s_addr >> 24) & 0xFF; - addr6.sin6_addr.s6_addr[13] = (s_addr >> 16) & 0xFF; - addr6.sin6_addr.s6_addr[14] = (s_addr >> 8) & 0xFF; - addr6.sin6_addr.s6_addr[15] = (s_addr) & 0xFF; + addr6.sin6_addr.s6_addr[12] = (pg_s_addr >> 24) & 0xFF; + addr6.sin6_addr.s6_addr[13] = (pg_s_addr >> 16) & 0xFF; + addr6.sin6_addr.s6_addr[14] = (pg_s_addr >> 8) & 0xFF; + addr6.sin6_addr.s6_addr[15] = (pg_s_addr) & 0xFF; memcpy(addr, &addr6, sizeof(addr6)); } @@ -448,11 +448,11 @@ { struct sockaddr_in addr4; struct sockaddr_in6 addr6; - uint32 s_addr; + uint32 pg_s_addr; int i; memcpy(&addr4, addr, sizeof(addr4)); - s_addr = ntohl(addr4.sin_addr.s_addr); + pg_s_addr = ntohl(addr4.sin_addr.s_addr); memset(&addr6, 0, sizeof(addr6)); @@ -461,10 +461,10 @@ for (i = 0; i < 12; i++) addr6.sin6_addr.s6_addr[i] = 0xff; - addr6.sin6_addr.s6_addr[12] = (s_addr >> 24) & 0xFF; - addr6.sin6_addr.s6_addr[13] = (s_addr >> 16) & 0xFF; - addr6.sin6_addr.s6_addr[14] = (s_addr >> 8) & 0xFF; - addr6.sin6_addr.s6_addr[15] = (s_addr) & 0xFF; + addr6.sin6_addr.s6_addr[12] = (pg_s_addr >> 24) & 0xFF; + addr6.sin6_addr.s6_addr[13] = (pg_s_addr >> 16) & 0xFF; + addr6.sin6_addr.s6_addr[14] = (pg_s_addr >> 8) & 0xFF; + addr6.sin6_addr.s6_addr[15] = (pg_s_addr) & 0xFF; memcpy(addr, &addr6, sizeof(addr6)); } also on my http://www.lerctr.org/~ler/postgresql page. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ip.patch Description: Binary data pgp0.pgp Description: PGP signature
[PATCHES] UnixWare patches placed on my www site
I've put my 2 pending 7.4Beta2 Patches up on my website at: http://www.lerctr.org/~ler/postgresql/ the unixware.thread.patch file is the bits needed to allow --enable-thread-safety to work. the unixware.shlib.patch file places an absolute pathname in DT_SONAME for the shared library. this will allow us to NOT have to muck with LD_LIBRARY_PATH nor symlinks out of /usr/lib/ These are against today's CVS. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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
[PATCHES] unixware having FULL pathnames in DT_SONAME
Here is a patch to make PostgreSQL use a full path in DT_SONAME for UnixWare. Please apply. Index: src/Makefile.shlib === RCS file: /projects/cvsroot/pgsql-server/src/Makefile.shlib,v retrieving revision 1.67 diff -u -r1.67 Makefile.shlib --- src/Makefile.shlib 21 Mar 2003 17:18:34 - 1.67 +++ src/Makefile.shlib 30 Aug 2003 20:11:21 - @@ -191,7 +191,7 @@ else LINK.shared = $(CC) -G endif - LINK.shared += -Wl,-z,text -Wl,-h,$(soname) + LINK.shared += -Wl,-z,text -Wl,-h,$(libdir)/$(soname) endif ifeq ($(PORTNAME), cygwin) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 unixware.shlib.patch Description: Binary data ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Preliminary UnixWare threads stuff
Here is the preliminary UnixWare threads patch. I hard-coded the HAVE_POSIX_GETPWUID_R define as I'm not sure how to do the configure stuff? Index: src/port/threads.c === RCS file: /projects/cvsroot/pgsql-server/src/port/threads.c,v retrieving revision 1.2 diff -u -r1.2 threads.c --- src/port/threads.c 4 Aug 2003 00:43:33 - 1.2 +++ src/port/threads.c 8 Aug 2003 02:52:29 - @@ -40,13 +40,18 @@ pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer, size_t buflen, struct passwd ** result) { -#if defined(USE_THREADS) && defined(HAVE_GETPWUID_R) +#if defined(USE_THREADS) && defined(HAVE_GETPWUID_R) && !defined(HAVE_POSIX_GETPWUID_R) /* * broken (well early POSIX draft) getpwuid_r() which returns 'struct * passwd *' */ *result = getpwuid_r(uid, resultbuf, buffer, buflen); +#elsif defined(USE_THREADS) && defined(HAVE_GETPWUID_R) && defined(HAVE_POSIX_GETPWUID_R) + /* + * current POSIX / SUSv2 getpwuid_r() + */ + return getpwuid_r(uid,resultbuf,buffer,buflen,result); #else /* no getpwuid_r() available, just use getpwuid() */ *result = getpwuid(uid); Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.11 diff -u -r1.11 unixware --- src/template/unixware 4 Sep 2002 22:54:18 - 1.11 +++ src/template/unixware 8 Aug 2003 02:52:29 - @@ -1,5 +1,11 @@ +SUPPORTS_THREADS=yes if test "$GCC" = yes; then - CFLAGS=-O2 + CFLAGS="-O2 -DHAVE_POSIX_GETPWUID_R" + THREAD_CFLAGS="-pthread -D_REENTRANT" + NEED_REENTRANT_FUNC_NAMES=yes else - CFLAGS='-O -K inline' + CFLAGS='-O -K inline -DHAVE_POSIX_GETPWUID_R' + THREAD_CFLAGS="-D_REENTRANT -K pthread -DHAVE_POSIX_GETPWUID_R" + NEED_REENTRANT_FUNC_NAMES=yes fi + This is BEFORE Bruce's rename of threads.c to thread.c -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pg.patch Description: Binary data ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] UPDATED UnixWare Threads Patch.
--On Friday, August 08, 2003 18:56:45 -0500 Larry Rosenman <[EMAIL PROTECTED]> wrote: Here is the updated UnixWare threads patch. I need some help to set the HAVE_POSIX_GETPWUID_R define from configure, but this will suffice for now. This also includes my recommendation for the Compiler Bug issue. Please Apply, and if one of the configure guru's can help here, I'd be most appreciative. Grr. I'm an idiot, the following is a CORRECTED version, basically s/#elsif/#elif/ Index: src/port/thread.c === RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v retrieving revision 1.2 diff -u -r1.2 thread.c --- src/port/thread.c 8 Aug 2003 03:09:56 - 1.2 +++ src/port/thread.c 9 Aug 2003 00:47:00 - @@ -40,13 +40,18 @@ pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer, size_t buflen, struct passwd ** result) { -#if defined(USE_THREADS) && defined(HAVE_GETPWUID_R) +#if defined(USE_THREADS) && defined(HAVE_GETPWUID_R) && !defined(HAVE_POSIX_GETPWUID_R) /* * broken (well early POSIX draft) getpwuid_r() which returns 'struct * passwd *' */ *result = getpwuid_r(uid, resultbuf, buffer, buflen); +#elif defined(USE_THREADS) && defined(HAVE_GETPWUID_R) && defined(HAVE_POSIX_GETPWUID_R) + /* + * SUSv2/POSIX getpwuid_r + */ + return getpwuid_r(uid, resultbuf, buffer, buflen, result); #else /* no getpwuid_r() available, just use getpwuid() */ *result = getpwuid(uid); Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.11 diff -u -r1.11 unixware --- src/template/unixware 4 Sep 2002 22:54:18 - 1.11 +++ src/template/unixware 9 Aug 2003 00:47:00 - @@ -1,5 +1,13 @@ +SUPPORTS_THREADS=yes if test "$GCC" = yes; then - CFLAGS=-O2 + CFLAGS="-O2 -DHAVE_POSIX_GETPWUID_R" + THREAD_CFLAGS="-pthread -D_REENTRANT" + NEED_REENTRANT_FUNC_NAMES=yes else - CFLAGS='-O -K inline' +# the -Kno_host is temporary for a bug in the compiler. See -hackers +# discussion on 7-8/Aug/2003. +# when the 7.1.3UP3 or later compiler is out, we can do a version check. + CFLAGS='-O -Kinline,no_host -DHAVE_POSIX_GETPWUID_R' + THREAD_CFLAGS="-D_REENTRANT -K pthread -DHAVE_POSIX_GETPWUID_R" + NEED_REENTRANT_FUNC_NAMES=yes fi -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pg.patch.2003-08-08 Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] UPDATED UnixWare Threads Patch.
Here is the updated UnixWare threads patch. I need some help to set the HAVE_POSIX_GETPWUID_R define from configure, but this will suffice for now. This also includes my recommendation for the Compiler Bug issue. Please Apply, and if one of the configure guru's can help here, I'd be most appreciative. LER Index: src/port/thread.c === RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v retrieving revision 1.2 diff -u -r1.2 thread.c --- src/port/thread.c 8 Aug 2003 03:09:56 - 1.2 +++ src/port/thread.c 8 Aug 2003 23:53:35 - @@ -40,13 +40,18 @@ pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer, size_t buflen, struct passwd ** result) { -#if defined(USE_THREADS) && defined(HAVE_GETPWUID_R) +#if defined(USE_THREADS) && defined(HAVE_GETPWUID_R) && !defined(HAVE_POSIX_GETPWUID_R) /* * broken (well early POSIX draft) getpwuid_r() which returns 'struct * passwd *' */ *result = getpwuid_r(uid, resultbuf, buffer, buflen); +#elsif defined(USE_THREADS) && defined(HAVE_GETPWUID_R) && defined(HAVE_POSIX_GETPWUID_R) + /* + * SUSv2/POSIX getpwuid_r + */ + return getpwuid_r(uid, resultbuf, buffer, buflen, result); #else /* no getpwuid_r() available, just use getpwuid() */ *result = getpwuid(uid); Index: src/template/unixware === RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.11 diff -u -r1.11 unixware --- src/template/unixware 4 Sep 2002 22:54:18 - 1.11 +++ src/template/unixware 8 Aug 2003 23:53:35 - @@ -1,5 +1,13 @@ +SUPPORTS_THREADS=yes if test "$GCC" = yes; then - CFLAGS=-O2 + CFLAGS="-O2 -DHAVE_POSIX_GETPWUID_R" + THREAD_CFLAGS="-pthread -D_REENTRANT" + NEED_REENTRANT_FUNC_NAMES=yes else - CFLAGS='-O -K inline' +# the -Kno_host is temporary for a bug in the compiler. See -hackers +# discussion on 7-8/Aug/2003. +# when the 7.1.3UP3 or later compiler is out, we can do a version check. + CFLAGS='-O -Kinline,no_host -DHAVE_POSIX_GETPWUID_R' + THREAD_CFLAGS="-D_REENTRANT -K pthread -DHAVE_POSIX_GETPWUID_R" + NEED_REENTRANT_FUNC_NAMES=yes fi -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pg.patch.2003-08-08 Description: Binary data ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
--On Friday, July 25, 2003 03:28:55 -0500 Andrew Dunstan <[EMAIL PROTECTED]> wrote: Finally I understand the issue, I think. But wouldn't an ordinary user on SCO wanting to install a private copy of Pg then have to hack the Makefiles to change/remove the abolute DT_SONAME? If so, that seems to me to mandate that this not be in the vanilla distribution. OS Vendors commonly make changes like this in software versions they distribute - that's a different thing from putting it in the standard distribution, ISTM. The benefit Larry cites seems to me to be small - presumably his Makefiles must include "-L /usr/local/pgsql/lib", so adding "-R /usr/local/pgsql/lib" doesn't look like a big thing. Adding an Rpath to executables to use libs in non-standard locations is very common, surely? except for things like PHP that create YASO (Yet Another Shared Object), and do NOT require the base EXECUTABLE to be recompiled, and use broken tools (e.g. libtool) to build the .SO. Maybe this needs to be YACO (yet another configure option) the option proposed would Do the right thing with a private copy, as it would make the DT_SONAME for their private copy their path. LER ] cheers andrew Larry wrote --On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? We can discuss adding the ability, but I'm against enforcing it by default. I belive that the issue is not broken systems, but broken practice. No, the issue is precisely that someone is proposing to break reasonable, useful practice to accomodate broken systems. No one is claiming that absolute sonames make the system more featureful or useful. In fact, it was admitted that it would have the reverse effect. The only argument for absolute sonames that was brought forth was that some older systems have security holes that can be worked around in this manner. For an example of ADDING to the usefulness, UnixWare has no ld.so.conf, or ldconfig equivalent. For ALL my PostgreSQL apps, I either need to specify -R/usr/local/pgsql/lib on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH environment variable set. The absolute DT_SONAME will fix that issue on THIS platform, which is why the ABILITY of an INDIVIDUAL port to set an absolute DT_SONAME would be useful. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)------- TIP 4: Don't 'kill -9' the postmaster -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
--On Friday, July 25, 2003 11:58:18 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? We can discuss adding the ability, but I'm against enforcing it by default. I belive that the issue is not broken systems, but broken practice. No, the issue is precisely that someone is proposing to break reasonable, useful practice to accomodate broken systems. No one is claiming that absolute sonames make the system more featureful or useful. In fact, it was admitted that it would have the reverse effect. The only argument for absolute sonames that was brought forth was that some older systems have security holes that can be worked around in this manner. For an example of ADDING to the usefulness, UnixWare has no ld.so.conf, or ldconfig equivalent. For ALL my PostgreSQL apps, I either need to specify -R/usr/local/pgsql/lib on the EXECUTABLE build, or make sure there is a GLOBAL LD_LIBRARY_PATH environment variable set. The absolute DT_SONAME will fix that issue on THIS platform, which is why the ABILITY of an INDIVIDUAL port to set an absolute DT_SONAME would be useful. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
--On Friday, July 25, 2003 09:37:04 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: Universal Practice does NOT equal Security and Usability. Please consider what Kean is saying here. What Kean is saying is that your system is insecure if you have a setuid executable that references shared libraries with nonabsolute sonames and you have a system (an "older system") that contains a particular bug in its run-time dynamic loader that it obeys LD_LIBRARY_PATH for setuid executables. That is fairly common knowledge, and that's why LD_LIBRARY_PATH is ignored for setuid executables on all properly functioning operating systems. If your system is broken in that particular way, upgrade your system or don't use setuid programs at all. Those are the only sane choices. It is not an acceptable choice to disable all valid uses of nonabsolute sonames for all users, just because some users are running on broken systems with obvious security flaws. I disagree STRONGLY with what you are saying here. What harm does it do to add the ABILITY for a port to use a ABSOLUTE DT_SONAME? All the SYSTEM SUPPLIED .so's on UnixWare use an absolute DT_SONAME, and I feel that we should build libpq to supply same on UnixWare, and Kean suggests that the prefered, SCO recommended way on OpenServer is to do the same. I belive that the issue is not broken systems, but broken practice. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2] (fwd)
To keep this on the list. PG Core: I think Kean makes good points, and adding infrastructure to do it with absolute pathnames in the shared libs would be a GOOD thing, and let the OS Specific maintainer(s) enable as their current or future practice dictates. LER Forwarded Message Date: Thursday, July 24, 2003 04:33:12 -0700 From: Kean Johnston <[EMAIL PROTECTED]> To: Larry Rosenman <[EMAIL PROTECTED]> Cc: Peter Eisentraut <[EMAIL PROTECTED]> Subject: Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2] These concerns might have some merit, but the solution could not possibly be to only fix this on one platform, because the mechanisms are the same I was not trying to re-architect PostgreSQL's build system. I submitted a patch for a specific OS that made it behave the way the vendor (us) recommends you build things. If the PG folks dont want to accept the patch thats really quite OK with me I will just apply it myself every time there is a new release. I am not evangelizing for this to be a universal change, but I thiunk that decling the OS patch becuase all othr OSes haven't done the same thing is a wee bit harsh, but I have no emotional attachment to this issue. everywhere. That said, it seems the universal practice is not to put full sonames into shared libraries, so it seems better that our libraries follow that practice. Otherwise it will be only a matter of time before someone comes out of the wood and claims that libraries will full sonames are a big whatever-else problem. I mean no offence when I say that that is an extremely weak argument. It used to be universal practice that if you wanted a small pause in the kernel you could do: for (spin = 0; spin < 100; spin++) ; And now optimizers and faster CPUs and whatever make that plainly wrong. But that aside I would also say that that position is wrong. libtool goes to some considerable lengths to figure out how to hard-code paths into shared libraries. It just rarely gets it right. Much of the "wisdom" about shared libraries these days comes from folks reading libtool's info page. Most people just dont care about the issue as long as it sorta-kinda works, so they just accept what they read. But libtool does many many things incorrectly, often in the name of expediency. Its not a bad program, it just has a different design goal. But I digress. If Peter agrees in principle that not having direct pathnames can be a problem then not at least taking the time to investigate or analyze the impact becuase of some potential future misunderstanding of the issue is a bit short-sighted. I can hear the halls of Microsoft ringing with "hey lets not fix that bug, someone in the future will complain about it if we do, or chips will get so fast that people wont mind rebooting their OS every other mouse click" :) Universal Practice does NOT equal Security and Usability. How true ... just look at sendmail :) *oops* ... was that my aloud voice? :) Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
--On Wednesday, July 23, 2003 12:20:34 +0200 Peter Eisentraut <[EMAIL PROTECTED]> wrote: Larry Rosenman writes: Why do this at all? Security. Having shared libraries without full SONAME's is a big security risk. There have been any number of huge explots based around this. Point me at any Solaris machine <= 2.7, or any OSR5 system < 507 or any FreeBSD system <= 4.0 and I can get root with 1 tiny program thats on all of them: xterm. It has long upset me, and I am done trying to convince them, but libtool encourages the worst possible .so practices, and may programs seem to have picked up those equally bad practices. There is no need for futzing with ld.conf and the like if people take the time to construct shared libraries propperly. Yes it can be a pain to bootstrap but the reward is very well worth the effort it takes. These concerns might have some merit, but the solution could not possibly be to only fix this on one platform, because the mechanisms are the same everywhere. That said, it seems the universal practice is not to put full sonames into shared libraries, so it seems better that our libraries follow that practice. Otherwise it will be only a matter of time before someone comes out of the wood and claims that libraries will full sonames are a big whatever-else problem. Universal Practice does NOT equal Security and Usability. Please consider what Kean is saying here. Kean, Please respond. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] PG Patch [openserver followup]
Forwarded Message Date: Saturday, July 19, 2003 16:10:36 -0700 From: Kean Johnston <[EMAIL PROTECTED]> To: Larry Rosenman <[EMAIL PROTECTED]> Cc: Subject: Re: PG Patch I'm trying to get a discussion going, as Bruce wants to do it right for ALL platforms or none. It probably WONT happen for 7.3.4, but WILL (If I have my way) for 7.4.0. Ok then let me explain the issue. You can forward this to Bruce since I haven't heard from him yet. As you know, the run-time link editor (RTLD) is responsible for loading an ELF program, resolving its dependent libraries and symbols, setting things up for _start, and calling it. There are a few ELF dynamic tags that come into play. The ones we care about are: DT_SONAME This is the name of the shared object that the RTLD will try to load. DT_RPATH Specifies the list of paths to search for dependencies (old way) DT_RUNPATH Specifies the list of paths to search for dependencies (new way) DT_NEEDED Lists the dependencies for this object There is also one environment variable that is used at load time to resolve dependencies, viz. LD_LIBRARY_PATH. The gABI defines how and where these are used, but this is a basic summary. I refer to the current object and the dependent object. The current object is the entity which is having its dynamic section interpreted. This is the executable or shared library that has a dependency that needs to be loaded by the RTLD. The dependent object is the name of the actual dependency, and comes from the DT_NEEDED list. 1) If the dependent object name contains a / use the name directly, with no path searching. 2) Search along DT_RPATH if the current object doesnt have DT_RUNPATH defined. DT_RPATH is a colon separated list of paths. 3) Search along LD_LIBRARY_PATH which is also a colon separated list of paths. Only do this if the process does not have elevated (i.e setuid or setgid) priveliges(*). 4) If the dependency still hasnt been met, search along DT_RUNPATH (if defined for the current). DT_RUNPATH is a colon separated list of path names. 5) If we still havent found it, look in the standard system places. 6) If we still havent resolved the dependency, bail. (*) this is the kicker. There are *MANY* older systems out there that have RTLD bugs that do not obey this rule. Consider the following. Most systems have xterm. xterm is very frequently setuid root. All you need to do is run dump -Lv on xterm to see if there are any shared libraries with no absolute path names, or any of the dependencies of any of the libraries, and you can get root like this. Let say, as is fairly common on older systems, that libX11.so does not have a fully qualified path name in its DT_SONAME. When xterm is linked, it will have a DT_NEEDED of libX11.so.5 or .6 or whatever, without an absolute path. That means that it will use the searching algorithms described above. All I need to do to get root is craft up (fairly easily) a libX11.so.5 that has, in a call I know xterm will use like XOpenDisplay, code that copies /bin/sh to somewhere and makes it setuid root. Now I put that hacked libX11.so.5 in my home directory, set LD_LIBRARY_PATH=$HOME, run xterm, and I've got a root shell. This can all be so easily avoid by rule (1) above. Always hard-code your libary names. Its a pain sometimes, to be sure, as I will describe below, but it is completely unambiguous, its secure and it is quicker. Granted the RTLD isnt that slow searching paths but hey, every bit counts. Before going in to detail on the problems of using absolute path names (there is always a catch, isn't there?), just a quick refresher on how these various dynamic tags get set in an ELF object. This varies from system to system but almost all system suse some subtle variation of the following. AIX is a bit funky as I recall. DT_RPATH is set if the link editor (ld) encounterd LD_RUN_PATH in the environment at link edit time. Thus doing something like: LD_RUN_PATH=/foo:/bar ld -o libfnoz.so blah.o would set DT_RPATH to /foo:/bar. DT_RUNPATH is set by the -R option on System-V-ish link editors, and by -rpath with GNU-ish ones (I think, I am no GNU ld expert, please correct me if I am wrong). DT_SONAME is set by -h on System-V-ish link editors and by -soname on GNU-ish ones. DT_NEEDED is set by any ELF link editor based on the -l options or explicit linkage against another shared object. It uses the DT_SONAME from the dependency to put in the object's DT_NEEDED list. While absolute path names are the way to fly, in general, they have their drawbacks too. First, it can be a right royal pain to bootstrap things. Consider this. You are building a program. As part of its build, it builds a shared library, and link edits it with an absolute DT_SONAME. Later in the build you link a program against it, and you want to use that program in the build (perhaps executing it to produce some intermediate file or whatever). If this is the very fir
Re: [PATCHES] PG Patch (fwd)
More on the shared lib stuff. I'd LIKE to get a discussion of this (after just talking to Bruce on the phone). If I need to repost Kean's comments to -HACKERS, let me know. LER Forwarded Message Date: Saturday, July 19, 2003 13:50:55 -0700 From: Kean Johnston <[EMAIL PROTECTED]> To: Larry Rosenman <[EMAIL PROTECTED]> Cc: Subject: Re: PG Patch Larry Rosenman wrote: BTW, you mentioned gAPI, what's the un-TLA'ing of that, and a WWW ref? gABI - General Application Binary Interface. http://www.sco.com/developers/gabi Oh and this isnt a SCO-only thing, most UNIXes conform to it to varying degrees. Is the stuff you brought up the reason I always have to futz with LD_LIBRARY_PATH for the libpq.so on UnixWare7? Almost certainly. I havent looked at the UnixWare compile, but it too can be fixed by using -h with a full pathname, or at least using -R correctly, which is a workable but less preferable solution. Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] PG Patch (fwd) [openserver patch followup #2]
2nd followup from Kean. LER Forwarded Message Date: Friday, July 18, 2003 23:43:55 -0700 From: Kean Johnston <[EMAIL PROTECTED]> To: Larry Rosenman <[EMAIL PROTECTED]> Cc: Subject: Re: PG Patch Larry Rosenman wrote: I got a question from the PG Core Team (Bruce Momjian) about the rpathdir portion of your patch. Why can't it use libdir? Or can we wrap it in .if (port,=,sco) type stuff? Sorry I forgot to anwer that portion of the question. The only place that used RPATHDIR *is* wrapped up in if port=sco. But why not use just libdir? Well the rule for making shared libraries is shared across multiple makefiles. Although I only set it for the main interface libraries, I had originally set it for all the dynamically loadable modules too, and for those, libdir isnt what you want, you want datadir or whatever its called (I'm too lazy to go look now). So I needed variable the lower level makefiles could specify that get used in the top level makefile. Why do this at all? Security. Having shared libraries without full SONAME's is a big security risk. There have been any number of huge explots based around this. Point me at any Solaris machine <= 2.7, or any OSR5 system < 507 or any FreeBSD system <= 4.0 and I can get root with 1 tiny program thats on all of them: xterm. It has long upset me, and I am done trying to convince them, but libtool encourages the worst possible .so practices, and may programs seem to have picked up those equally bad practices. There is no need for futzing with ld.conf and the like if people take the time to construct shared libraries propperly. Yes it can be a pain to bootstrap but the reward is very well worth the effort it takes. Suffice it to say that I believe that *EVERY* .so should have an absolute SONAME. There are still a few I need to clean up in 507 but most of them are correct. If you're not on the up-and-up with DT_RUNPATH, DT_RPATH and SONAME ELF headers I suggest for light reading that you peruse the gABI. Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] PG Patch (fwd) [OpenServer followup #1]
Follow-up to a question from Bruce on the phone, re: the open server patch 2nd to follow. Kean has graciously agreed to answer questions if y'all need them answered. LER Forwarded Message Date: Friday, July 18, 2003 23:24:47 -0700 From: Kean Johnston <[EMAIL PROTECTED]> To: Larry Rosenman <[EMAIL PROTECTED]> Cc: Subject: Re: PG Patch Larry Rosenman wrote: I got a question from the PG Core Team (Bruce Momjian) about the rpathdir portion of your patch. Why can't it use libdir? Or can we wrap it in .if (port,=,sco) type stuff? There's concern that we'll break other platforms. Since OSR5 was the only platform that defines it, not much chance of breaking anything, and other platform may find it useful when people finally understand all of the security implications about using DT_RUNPATH in ELF. I *ALWAYS* hard-code the full path so that libraries cannot be subverted by a user by setting LD_LIBRARY_PATH. Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PERL (fwd)
I was dealing with SCO on PG issues, and they supplied the following patch against 7.3.3 for SCO OSR5. Can it be massaged for 7.4? LER Forwarded Message Date: Tuesday, July 15, 2003 13:09:40 -0700 From: Kean Johnston <[EMAIL PROTECTED]> To: Larry Rosenman <[EMAIL PROTECTED]> Cc: Subject: Re: PERL If you can get patches for OSR5 out QUICKLY, we can get them integrated on 7.4 which enters beta next week. Attached. Kean -- End Forwarded Message -- -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 --- Begin Message --- If you can get patches for OSR5 out QUICKLY, we can get them integrated on 7.4 which enters beta next week. Attached. Kean --- ./src/interfaces/ecpg/lib/Makefile.osd 2003-06-23 11:48:33.0 -0700 +++ ./src/interfaces/ecpg/lib/Makefile 2003-06-23 13:08:35.0 -0700 @@ -28,6 +28,7 @@ # Shared library stuff include $(top_srcdir)/src/Makefile.shlib +RPATHDIR=$(libdir)/ install: all installdirs install-lib --- ./src/interfaces/libpgtcl/Makefile.osd 2003-06-23 11:49:03.0 -0700 +++ ./src/interfaces/libpgtcl/Makefile 2003-06-23 13:08:56.0 -0700 @@ -31,6 +31,7 @@ # Shared library stuff include $(top_srcdir)/src/Makefile.shlib +RPATHDIR=$(libdir)/ install: all installdirs install-headers install-lib --- ./src/interfaces/libpq/Makefile.osd 2003-06-23 11:50:16.0 -0700 +++ ./src/interfaces/libpq/Makefile 2003-06-23 13:09:13.0 -0700 @@ -36,6 +36,7 @@ # Shared library stuff include $(top_srcdir)/src/Makefile.shlib +RPATHDIR=$(libdir)/ backend_src = $(top_srcdir)/src/backend --- ./src/pl/plperl/GNUmakefile.osd 2003-06-23 11:37:00.0 -0700 +++ ./src/pl/plperl/GNUmakefile 2003-06-23 13:07:00.0 -0700 @@ -18,6 +18,11 @@ override CFLAGS := $(filter-out -Wall -Wmissing-declarations -Wmissing-prototypes, $(CFLAGS)) endif +# This fails on SCO with -ztext, becuase libcrypt.a is a COFF library +ifeq ($(PORTNAME), sco) +override perl_embed_ldflags := $(filter-out -lcrypt, $(perl_embed_ldflags)) +endif + override CPPFLAGS := -I$(srcdir) -I$(perl_archlibexp)/CORE $(CPPFLAGS) @@ -30,7 +35,6 @@ include $(top_srcdir)/src/Makefile.shlib - all: all-lib SPI.c: SPI.xs --- ./src/template/sco.osd 2003-06-23 10:11:18.0 -0700 +++ ./src/template/sco 2003-06-23 10:11:07.0 -0700 @@ -2,6 +2,6 @@ CFLAGS=-O2 else CFLAGS=-O + CC="$CC -b elf" fi -CC="$CC -b elf" --- ./src/Makefile.shlib.osd2003-06-23 11:55:26.0 -0700 +++ ./src/Makefile.shlib2003-06-23 13:05:14.0 -0700 @@ -171,7 +171,7 @@ else LINK.shared= $(CC) -G endif - LINK.shared += -Wl,-z,text -Wl,-h,$(soname) + LINK.shared += -Wl,-z,text -Wl,-h,$(RPATHDIR)$(soname) endif ifeq ($(PORTNAME), svr4) --- End Message --- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] Interval Patch
This is against 7.3.3 sources, but it fixes the TODO * Have SELECT '13 minutes'::interval display zero seconds in ISO datestyle *** datetime.c.orig Sat May 3 23:30:35 2003 --- datetime.c Tue Jun 24 15:54:39 2003 *** *** 3498,3504 is_nonzero = TRUE; } /* otherwise, integer seconds only? */ ! else if (tm->tm_sec != 0) { sprintf(cp, ":%02d", abs(tm->tm_sec)); cp += strlen(cp); --- 3498,3504 is_nonzero = TRUE; } /* otherwise, integer seconds only? */ ! else { sprintf(cp, ":%02d", abs(tm->tm_sec)); cp += strlen(cp); -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 datetime.patch Description: Binary data ---(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: [PATCHES] Thread configure flag
--On Saturday, June 21, 2003 15:57:54 -0400 Bruce Momjian <[EMAIL PROTECTED]> wrote: \ Well, when the packagers wrap up 7.4 they're going to need to make a call. Either it's not going to be thread-safe, and the work was in vain, or it's thread-safe and the concerns about the supposed performance hits are not addressed. Well, it will not be in vain because people can still compile their own builds. I am not sure if we support enough platforms to enable all this by default in 7.4, and it could cause confusion. Did anyone see my comments about -Kthread/-Kpthread on UnixWare? That throws another mix into it. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])