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 entrystructfieldencoding/structfield/entry entrytypeint4/type/entry entry/entry ! entryCharacter encoding for this database/entry /row row --- 1954,1962 entrystructfieldencoding/structfield/entry entrytypeint4/type/entry entry/entry ! entryCharacter encoding for this database. The ! functionpg_encoding_to_char/function can be used to translate ! this to the encoding name used/entry /row -- 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 entrystructfieldencoding/structfield/entry entrytypeint4/type/entry entry/entry ! entryCharacter encoding for this database/entry /row row --- 1954,1962 entrystructfieldencoding/structfield/entry entrytypeint4/type/entry entry/entry ! entryCharacter encoding for this database. The ! functionpg_encoding_to_char/function can be used to translate ! this to the encoding name used/entry /row ---(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, 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
Re: [PATCHES] Reduce dependancies of postmaster (without --as-needed)
On Nov 28 2005, Tom Lane wrote:
Larry Rosenman ler@lerctr.org 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, Tom Lane wrote: Larry Rosenman ler@lerctr.org 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] [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
[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
[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
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: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 SELECT 'infinity'::float8; ! ERROR: invalid input syntax for type double precision: infinity SELECT ' -INFINiTY '::float8; ! ERROR: invalid input syntax for type double precision: -INFINiTY -- bad special inputs SELECT 'N A N'::float8; ERROR: invalid input syntax for type double precision: N A N *** *** 70,88 SELECT ' INFINITYx'::float8; ERROR: invalid input syntax for type double precision: INFINITYx SELECT 'Infinity'::float8 + 100.0; ! ERROR: type double precision value out of range: overflow SELECT 'Infinity'::float8 / 'Infinity'::float8; ! ?column
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] 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
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
[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] 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 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] 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] 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 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]
--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] (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 (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)
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 [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 first time you are compiling the program
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 ---BeginMessage--- 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
