[HACKERS] Re: [PATCHES] Makefile.PL for Pg.so
* Peter Eisentraut [EMAIL PROTECTED] [010825 18:14]: Larry Rosenman writes: Can we do something similar for the distribution to set the RUNPATH for Pg.so? AFAICT, Pg.so does get the runpath set correctly. Are you saying it doesn't work on your system or do you want to get rid of the recompilation during installation? It doesn't work on this systsm . (you still have a login here). LER -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter -- 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])
[HACKERS] Re: [PATCHES] Makefile.PL for Pg.so
* Peter Eisentraut [EMAIL PROTECTED] [010825 18:14]: Larry Rosenman writes: Can we do something similar for the distribution to set the RUNPATH for Pg.so? AFAICT, Pg.so does get the runpath set correctly. Are you saying it doesn't work on your system or do you want to get rid of the recompilation during installation? Oh, BTW, LD_RUN_PATH is *NOT* used to set the runpath on SVR5. That's why I needed to pass -R to the build. LER -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter -- 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]
[HACKERS] Re: [PATCHES] Makefile.PL for Pg.so
* Peter Eisentraut [EMAIL PROTECTED] [010814 16:58]: Larry Rosenman writes: I made the following patch, and it works for MY platform. Peter, Can we do something similar for the distribution to set the RUNPATH for Pg.so? This is an interesting idea. I'd rather rip out MakeMaker completely, but this might be a good start. I'm not familiar enough with the config / autoconf stuff to do a portable patch. Can you help in this area? LER -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter -- 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])
Re: [HACKERS] OID unsigned long long
* mlw [EMAIL PROTECTED] [010813 21:06]: I am thinking about embarking on changing the typedef of OID to unsigned long long. My plan is to make it conditional at configure time, i.e. #ifdef OID_ULONGLONG typedef unsigned long long Oid; #define OID_MAX ULLONG_MAX #else typedef unsigned int Oid; #define OID_MAX UINT_MAX #endif Aside from adding %llu to all the %u everywhere an OID is used in a printf, and any other warnings, are there any other things I should be specially concerned about? The wire protocol... LER -- 5-4-3-2-1 Thunderbirds are GO! http://www.mohawksoft.com ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Makefile.PL for Pg.so
I made the following patch, and it works for MY platform.
Peter,
Can we do something similar for the distribution to set the
RUNPATH for Pg.so?
Index: Makefile.PL
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/perl5/Makefile.PL,v
retrieving revision 1.17
diff -c -r1.17 Makefile.PL
*** Makefile.PL 2001/03/06 22:07:09 1.17
--- Makefile.PL 2001/08/13 04:12:28
***
*** 64,66
--- 64,77
];
}
+ sub MY::dynamic_lib {
+ package MY;
+ my $inherited= shift-SUPER::dynamic_lib(@_);
+ if (! -d $ENV{POSTGRES_LIB} ) {
+my $cwd = `pwd`;
+ chop $cwd;
+ $ENV{POSTGRES_LIB} = $cwd/../libpq;
+ }
+ $inherited=~ s@OTHERLDFLAGS =@OTHERLDFLAGS =-R$ENV{POSTGRES_LIB}@;
+ $inherited;
+ }
--
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])
[HACKERS] Re: Autoconf 2.50 is out (was Re: [PATCHES] Re: OpenUnix 8 Patch)
* Tom Lane [EMAIL PROTECTED] [010730 18:34]: I wrote: If autoconf releases were happening on a regular basis, we could get away with just tracking the released version of autoconf for these files. However, they aren't and we can't. Just moments after writing that, I was startled to read on another mailing list that the long-mythical Autoconf 2.50 is released! We should probably consider updating from autoconf 2.13 as our project standard to 2.50. However, I'd recommend waiting till Peter E. returns from his vacation to see what his opinion about it is. IIRC, he's been following that project, which I have not been. I also see LOTS of complaints about compat issues, which is why I just pulled the 2 files from ftp://ftp.gnu.org/pub/gnu/config when I generated that patch. Looks like they updated them again today: $ ftp ftp.gnu.org Connected to gnuftp.gnu.org. 220 ProFTPD 1.2.0pre10 Server (ProFTPD) [gnuftp.gnu.org] 331 Anonymous login ok, send your complete e-mail address as password. 230-If you have any problems with the GNU software or its downloading, please refer your questions to [EMAIL PROTECTED]. There are several mirrors of this archive, a complete list can be found on http://www.gnu.org/order/ftp.html. Please use one of the mirrors if possible. Archives of the GNU mailing lists can be found in ftp://ftp-mailing-list-archives.gnu.org/. Please note that the directory structure on ftp.gnu.org was redisorganzied fairly recently, such that there is a directory for each program. One side effect of this is that if you cd into the gnu directory, and do ls emacs* you will get a list of all the files in the emacs directory, but it will not be obvious from the ls output that you have to `cd emacs' before you can download those files. Note further the non-GNU programs that were formerly in gnu/ have moved to gnu/non-gnu/. Most of them were just pointers in the format program.README. If you are looking for such a file, be sure to check gnu/non-gnu/. 230 Anonymous access granted, restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp cd pub/gnu/config 250 CWD command successful. ftp pwd 257 /gnu/config is current directory. ftp dir 200 PORT command successful. 150 Opening ASCII mode data connection for file list. -rw-r--r-- 1 ftp ftp 38214 Jul 30 14:00 config.guess -rw-r--r-- 1 ftp ftp 27872 Jul 30 14:00 config.sub 226-Transfer complete. 226 Quotas off ftp Larry 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] (forw) Caldera OpenUNIX 8
I got a mailbox full for Peter, so here is information. Larry ROsenman - Forwarded message from Larry Rosenman [EMAIL PROTECTED] - From: Larry Rosenman [EMAIL PROTECTED] Subject: Caldera OpenUNIX 8 Date: Fri, 27 Jul 2001 11:58:01 -0500 Message-ID: [EMAIL PROTECTED] User-Agent: Mutt/1.3.19i X-Mailer: Mutt http://www.mutt.org/ To: [EMAIL PROTECTED] lerami.lerctr.org is now running Caldera's OpenUNIX 8 operating system which is UnixWare 7.1.1+fixes+Linux Kernel Personality. The tools (cc, et al) have just bug fixes. THere is also a LINUX mode, which is the full OpenLinux 3.1 userland on top of the UnixWare kernel with call mapping. If you have questions, let me know. 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 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: OID wraparound (was Re: [HACKERS] pg_depend)
Also, without OID's, how do you fix EXACT duplicate records that happen by accident? LER Original Message On 7/18/01, 3:46:30 PM, Rod Taylor [EMAIL PROTECTED] wrote regarding Re: OID wraparound (was Re: [HACKERS] pg_depend) : If OIDs are dropped a mechanism for retrieving the primary key of the last insert would be greatly appreciated. Heck, it would be useful now (rather than returning OID). I much prefer retrieving the sequence number after the insert than before insert where the insert uses it. Especially when trigger muckary is involved. -- Rod Taylor Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Lamar Owen [EMAIL PROTECTED] Cc: Bruce Momjian [EMAIL PROTECTED]; PostgreSQL-development [EMAIL PROTECTED] Sent: Wednesday, July 18, 2001 4:30 PM Subject: Re: OID wraparound (was Re: [HACKERS] pg_depend) Lamar Owen [EMAIL PROTECTED] writes: On Wednesday 18 July 2001 16:06, Tom Lane wrote: It remains to be debated exactly how users should control the choice for user tables, and which choice ought to be the default. I don't have a strong opinion about that either way, and am prepared to hear suggestions. SET OIDGEN boolean for database-wide default policy. CREATE TABLE WITH OIDS for individual tables? CREATE TABLE WITHOUT OIDS? Something along that line, probably. ?? Is this sort of thing addressed by any SQL standard (Thomas?)? OIDs aren't standard, so the standards are hardly likely to help us decide how they should work. I think the really critical choice here is how much backwards compatibility we want to keep. The most backwards-compatible way, obviously, is OIDs on by default and things work exactly as they do now. But if we were willing to bend things a little then some interesting possibilities open up. One thing I've been wondering about is whether an explicit WITH OIDS spec ought to cause automatic creation of a unique index on OID for that table. ISTM that any application that wants OIDs at all would want such an index... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Idea: recycle WAL segments, don't delete/recreate 'em
Err PG_DUMP nightly on a 38,000,000+row table that takes forever to dump/unload, and gets updated every 5 minutes with 256KChar worth of updates? Give me a FAST pg_dump, and I'll think about it, until then, no LER (PS: this is also a reason for making a pg_upgrade work IN PLACE on a table). LER Original Message On 7/18/01, 11:35:04 AM, Bruce Momjian [EMAIL PROTECTED] wrote regarding Re: [HACKERS] Idea: recycle WAL segments, don't delete/recreate 'em: Yes, but in a very roundabout way (or so it seems). The main point that I was trying to illustrate was that if a database supports point-in-time recovery, recycling of the only available log segments is a bad thing. And, yes, in practice if you have point-in-time recovery enabled you better archive your logs with your backup to ensure that you can roll forward as expected. I assume you are not going to do point-in-time recovery by keeping all the WAL segments around on the same disk. Of course not. As mentioned, you'd probably archive them with your backup(s). You mean the nigthly backup? Why not do a pg_dump and be done with it. You have to copy them off somewhere, right, and once you have copied them, why not reuse them? I'm not arguing that point. I stated recycling of the only available log segments. Once the log segment is archived (copied) elsewhere you have two available images of the same segment. You can rename the local copy. Yes, OK, I see now. As Tom mentioned, there would have to be some delay where we allow the WAL log to be archived before reusing it. A possible solution (as I mentioned before)) is to have 2 methods of logging available: circular and forward-recoverable. When a database is created, the creator selects which type of logging to perform. The log segments are exactly the same, only the recycling method is different. Will not fly. We need a solution that is flexible. Could you expand on that a little (ie. flexible in which way). Offering the user a choice of two is more flexible than offering no choice. We normally don't give users choices unless we can't come up with a win-win solution to the problem. In this case, we could just query to see if the WAL PIT archiver is running and handle tune reuse of log segments on the fly. In fact, my guess is that the PIT archiver will have to tell the system when it is done with WAL logs anyway. Hmmm... the more I look at this, the more interested I become. My assumption is that once a log is full the point-in-time recovery daemon will copy that off somewhere, either to a different disk, tape, or over the network to another machine. Once it is done making a copy, the WAL log can be recycled, right? Am I missing something here? Ok... I wasn't thinking of having a point-in-time daemon. Some other databases provide, for lack of a better term, user exits to allow user defined scripts or programs to be called to perform log segment archiving. This archiving is somewhat orthogonal to point-in-time recovery proper. Yep, once the archiving is complete, you can do whatever you want with the local log segment. We will clearly need something to transfer these WAL logs somewhere else, and it would be nice if it could be easily configured. I think a PIT logger daemon is the only solution, especially since tape/network transfer could take a long time. It would be forked by the postmaster so would cover all users and databases. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: OID wraparound (was Re: [HACKERS] pg_depend)
Didn't know about that one, at least from the reading of the docs... Thanks, You answered the question. I knew OID's weren't unique, but they are likely to be able to distinguish between 2 rows in the same table. Maybe ctid needs to be documented better? LER Original Message On 7/18/01, 4:32:28 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: OID wraparound (was Re: [HACKERS] pg_depend) : Bruce Momjian [EMAIL PROTECTED] writes: Also, without OID's, how do you fix EXACT duplicate records that happen by accident? How about tid's? SELECT tid FROM tab1. SELECT ctid, actually, but that is still the fallback. (Actually it always was --- OIDs aren't necessarily unique either, Larry.) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] NetBSD 1.5.1(HP300)
Reported to NetBSD as pr BIN/13486
LER
Original Message
On 7/16/01, 3:40:31 PM, Peter Eisentraut [EMAIL PROTECTED] wrote regarding
Re: [HACKERS] NetBSD 1.5.1(HP300):
Larry Rosenman writes:
When it trys to run the following:
configure:7174: gcc -o conftest -O2 -pipe -L/usr/local/lib conftest.c
-lz -lcrypt -lresolv -lcompat -lm -lutil -ledit 15
configure: failed program was:
#line 7170 configure
#include confdefs.h
int main() { return 0; }
$
that program dies:
$ cat conftest.c
#include confdefs.h
int main() { return 0; }
$ /lib conftest.c -lz -lcrypt -lresolv -lcompat -lm -lutil -ledit
$ ./conftest
/usr/libexec/ld.so: Undefined symbol _tputs in
conftest:/usr/lib/libedit.so.2.3
Yes, I've seen that before. The program links okay but does not execute
because of an undefined symbol. I think that's a linker bug. Why would
I
need a linker if it doesn't make sure the executable has fully resolved
symbols? This can be observed at least with NetBSD -ledit and OpenBSD
-lreadline.
Here's how I would expect it to work:
configure:3249: checking for readline
configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline 15
/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libreadline.so:
undefined reference to `tgetnum'
[snip]
collect2: ld returned 1 exit status
configure: failed program was:
#line 3260 configure
#include confdefs.h
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char readline();
int main() {
readline()
; return 0; }
[snip]
configure:3271: gcc -o conftest -O2 -g conftest.c -lreadline
-ltermcap 15
[success]
Can you take this to the OS developers?
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] NetBSD 1.5.1(HP300)
in testing CVS tip(sort of), I found that you need -lcurses with -ledit on NetBSD 1.5.1. _tputs in undefined otherwise. 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] iconv?
88591.646SE.b 88597.869.p 646DE.88591.d 865.88591.e 88591.646SE.d 88599.1254.b 646DK.88591.d 865.cpz 88591.646SE.e 88599.1254.d 646ES.88591.d 865.dk_pc 88591.646SE.p 88599.1254.e 646FR.88591.d 866.88595.b 88591.6937.d 88599.1254.p 646GB.88591.d 866.88595.d 88591.850.b 88599.857.b 646IT.88591.d 866.88595.e 88591.850.d 88599.857.d 646PT.88591.d 869.88597.b 88591.850.e 88599.857.e 646SE.88591.d 869.88597.d 88591.850.p 88599.857.p 6937.88591.d 869.88597.e 88591.860.b asc.88591.b 737.88597.b 869.88597.p 88591.860.d asc.88591.d 737.88597.d 88591.1252.b 88591.860.e asc.88591.e 737.88597.e 88591.1252.d 88591.860.p asc.88591.p 737.88597.p 88591.1252.e 88591.863.b asc.ebcdic 850.646.b 88591.1252.p 88591.863.d asc.ibm_ebcdic 850.646.d 88591.437.b 88591.863.e codesets 850.646.e 88591.437.d 88591.863.p dos.unicode.so 850.88591.b 88591.437.e 88591.865.b ebcdic.437 850.88591.d 88591.437.p 88591.865.d ebcdic.asc 850.88591.e 88591.646.b 88591.865.e eucJP.NWsjis.so 850.88591.p 88591.646.d 88591.865.p eucJP.sjis.so 850.cpz 88591.646.e 88591.asc.b iconv_data 850.dk_pc 88591.646.p 88591.asc.d kmods 852.88592.b 88591.646DE.b 88591.asc.e unicode.88591.so 852.88592.d 88591.646DE.d 88591.asc.p unicode.eucJP.so 852.88592.e 88591.646DE.e 88591.cpz unicode.sjis.so 852.88592.p 88591.646DE.p 88591.dk_pc unicode.utf.so 857.88599.b 88591.646DK.b 88591.roman8.dvt220.88591.b 857.88599.d 88591.646DK.d 88591.vt220.b vt220.88591.d 857.88599.e 88591.646DK.e 88591.vt220.d vt220.88591.e $ uname -a UnixWare lerami 5 7.1.1 i386 x86at SCO UNIX_SVR5 $ ---(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 -- 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: [HACKERS] way to pass NEW into function
What I did in a similar trigger was set a variable (of type RECORD) to NEW and then use that. (I actually used the appropriate fields, but record should... work) LER Original Message On 7/10/01, 4:22:34 PM, Mike Cianflone [EMAIL PROTECTED] wrote regarding [HACKERS] way to pass NEW into function: Is it possible to trick pg/sql to allow passing of the NEW record into a function? I've got a trigger that gets kicked off before an insert and I need to call another function and pass that record in, but doing a perform activate_event(NEW); /* my function is activate_event(OPAQUE) */ only spits out ERROR: NEW used in non-rule query. Is there a way to trick it into passing the NEW record into my function? Thanks for any pointers, Mike ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 2 gig file size limit
* Naomi Walker [EMAIL PROTECTED] [010706 17:57]: If PostgreSQL is run on a system that has a file size limit (2 gig?), where might cause us to hit the limit? PostgreSQL is smart, and breaks the table files up at ~1GB per each, so it's transparent to you. You shouldn't have to worry about it. LER -- Naomi Walker Chief Information Officer Eldorado Computing, Inc. 602-604-3100 ext 242 ---(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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] docs toolchain appears broke?
* Ian Lance Taylor [EMAIL PROTECTED] [010326 01:14]: Tom Lane [EMAIL PROTECTED] writes: Larry Rosenman [EMAIL PROTECTED] writes: gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml' cd sgml tar -cf ../programmer.tar --exclude=Makefile --exclude='*.sgml' --exclude=ref *.html -C `cd . pwd`/graphics catalogs.gif connections.gif tar: can't add file catalogs.gif : No such file or directory tar: can't add file connections.gif : No such file or directory gmake: *** [programmer.tar] Error 1 Kinda looks like Ian broke the compile-in-source-dir case while making the compile-in-separate-dir case work. Tut tut. Yes. My apologies. This patch is one way to fix things. This patch seems to work. Thanks. 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
Since the SCO UDK works on both UnixWare and OpenServer, I think we are pretty safe. Also, there was a post to -HACKERS about the accept bug and we changed the workaround to include OSR5. I'd leave it until disproved. I don't have a OSR5 installation to check it with, however. LER Original Message On 3/26/01, 12:05:55 PM, Thomas Lockhart [EMAIL PROTECTED] wrote regarding Re: [HACKERS] Re: Call for platforms: SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie Where did you see this? I don't find it in the archives or in Vince's database. In FAQ_SCO. I was looking to try to figure out what the differences were between the SCO products :) - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Re: Call for platforms
I would. 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 US Original Message On 3/26/01, 2:36:19 PM, Thomas Lockhart [EMAIL PROTECTED] wrote regarding Re: [HACKERS] Re: Call for platforms: "PPC750"? What's that? "PPC G3" might be more likely to mean something to onlookers ... Actually "G3" means nothing outside of Apple afaict. The 750 series is a follow-on to the 60x series, and there is a 7xxx series also. From my pov, using an accepted label, rather than a marketing (re)label, better indicates *what* this actually can run on. I'm not sure that I have it labeled correctly yet, but "G3" is not a step in the right direction. As we both found, it is difficult to wade through Apple's own docs to decipher which processor is actually built into the system. Should I put "Mac G3" in the comment section? - Thomas ---(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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] docs toolchain appears broke?
Was just trying to recreate my docs from CVS, using the same tools I've been using for months, and got the following: gmake -C sgml clean gmake[1]: Entering directory `/home/ler/pg-dev/pgsql/doc/src/sgml' rm -f catalog rm -f HTML.manifest *.html rm -rf *.1 *.l man1 manl manpage.refs manpage.links manpage.log rm -f *.rtf *.tex *.dvi *.aux *.log *.ps *.pdf gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml' gmake -C sgml programmer.html gmake[1]: Entering directory `/home/ler/pg-dev/pgsql/doc/src/sgml' (echo "PUBLIC \"-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN\" \"/usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl\""; \ echo "PUBLIC \"-//Norman Walsh//DOCUMENT DocBook Print Stylesheet//EN\" \"/usr/local/share/sgml/docbook/dsssl/modular/print/docbook.dsl\"") catalog jade -D . -D ./ref -D ./../graphics -d stylesheet.dsl -i output-html -t sgml book-decl.sgml programmer.sgml ln -sf programmer.html index.html gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml' cd sgml tar -cf ../programmer.tar --exclude=Makefile --exclude='*.sgml' --exclude=ref *.html -C `cd . pwd`/graphics catalogs.gif connections.gif tar: can't add file catalogs.gif : No such file or directory tar: can't add file connections.gif : No such file or directory gmake: *** [programmer.tar] Error 1 gmake: *** Deleting file `programmer.tar' $ this was after making a graphics directory. Did someone forget to add some files to 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
I'll take the deafening silence as a NO? LER * Larry Rosenman [EMAIL PROTECTED] [010323 16:59]: Can I get a go/nogo decision on whether these two functions can be #if'd out for 7.1? Thanks. LER Original Message On 3/22/01, 4:02:45 PM, Larry Rosenman [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : OK, it *IS* just a WARNING that the symbols are undefined. SO, can we get the _fini/_init stuff commented/taken out for 7.1? LER Original Message On 3/22/01, 3:38:59 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman [EMAIL PROTECTED] writes: My question is WHY are we using -Bsymbolic and/or -z text anyway? These options don't appear to buy us anything but grief on SVR[45] ELF systems.. I have no idea what -z text means to your linker, but if it has a -Bsymbolic option then it's a good bet that you need that. The ODBC driver contains some function names that duplicate names in the unixODBC driver manager. The driver's own references to these functions *must* be resolved to its own routines and not the manager's, else havoc ensues. But for some reason, the other way is the default on many platforms. Do not assume that you have this right just because the build succeeds. I found in testing on HPUX that not only could you build a wrongly linked driver, but it would actually load and connect. Only certain kinds of queries exhibited the problem. In short: better test it before you claim you have it fixed. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(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 -- 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
* Peter Eisentraut [EMAIL PROTECTED] [010324 17:35]: Tom Lane writes: Larry Rosenman [EMAIL PROTECTED] writes: I'll take the deafening silence as a NO? I was (a) waiting to see what Peter thought about it, Don't ask me, I don't know what this does... and (b) wondering whether you'd actually tested to see that the built ODBC driver does something useful. I'm not eager to risk a post-RC1 change that could conceivably break other platforms. Moving ODBC on UW from "doesn't compile" to "compiles" isn't enough of a reason to take the risk. You need to demonstrate that it moves all the way to "works". Methinks so too. then it'll have to wait for 7.2. I can't get enough bits to work, and no answer on pgsql-odbc yet. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ -- 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/users-lounge/docs/faq.html
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
* Bruce Momjian [EMAIL PROTECTED] [010321 23:08]: Works fine here. on a GCC platform, it does. I suspect this is a portability issue. LER Since I am playing with StarOffice, I figured I'd try --with-odbc, current sources, except for the big Bruce commit I just saw :-) UX:tsort: INFO: psqlodbc.o UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: convert.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: psqlodbc.o UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: misc.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: psqlodbc.o : libpsqlodbc.a cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26 UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file /usr/ccs/lib/crti.o gmake[3]: *** [libpsqlodbc.so.0.26] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/odbc' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 Why do WE define _fini? 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] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- 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])
Re: [HACKERS] Re: Call for platforms
4.3 is in RELEASE CANDIDATE right now. By the time we release, it should be -RELEASE or -STABLE. I'd include it as just 4.3. It will be the -RELEASE at the time we are. LER Original Message On 3/22/01, 8:50:26 AM, Thomas Lockhart [EMAIL PROTECTED] wrote regarding [HACKERS] Re: Call for platforms: FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber FreeBSD 4.3-BETA is good to go also ... Yeah, I'm not sure how to list that, or whether to bother. It is beta, 4.2 works fine (and nothing had to change for 4.3, right?) so maybe we just list it when 4.3 goes stable? Or is 4.3 sufficiently different that it would be good to list in the comments for the platform? - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
Can't we do something with atexit or other PORTABLE end stuff? I'll look at it for 7.2. LER Original Message On 3/22/01, 10:16:03 AM, Peter Eisentraut [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.: Larry Rosenman writes: cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26 UX:ld: ERROR: psqlodbc.o: symbol: '_fini' multiply defined; also in file /usr/ccs/lib/crti.o gmake[3]: *** [libpsqlodbc.so.0.26] Error 1 This is a known portability problem on Unixware (at least known to me) and probably other non-GCC setups. Why do WE define _fini? Because we need to 'fini' something, I suspect. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
In a very quick look I just made, I tend to agree with Tom, that the whole non-gcc, non-windows stuff should go. LER Original Message On 3/22/01, 10:20:11 AM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Peter Eisentraut [EMAIL PROTECTED] writes: Larry Rosenman writes: Why do WE define _fini? Because we need to 'fini' something, I suspect. See src/interfaces/odbc/psqlodbc.c line 126. It doesn't look to me like the _fini() does anything useful; could we take it out? We do not actually need the _init() anymore either. Possibly the whole #ifdef not-Windows segment (lines 92-132) is just asking for trouble and should be removed. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
Does this mean it's eligible to be fixed for 7.1? LER Original Message On 3/22/01, 11:05:29 AM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Peter Eisentraut [EMAIL PROTECTED] writes: It's supposed to work transparently for the library user. At least the _fini can probably be hooked in atexit, but the _init would probably have to be handled some other way. The _fini does nothing, and I already made a hack to cover lack of the _init (which seems not to get called on HPUX) --- see odbc/environ.c line 37. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
need to kill the _init too. Then we get other symbol issues, I think due to -Wl,z,text, but I'm not sure. ar crs libpsqlodbc.a `lorder info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o | tsort` UX:tsort: WARNING: Cycle in data UX:tsort: INFO: results.o UX:tsort: INFO: parse.o UX:tsort: INFO: info.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: execute.o UX:tsort: INFO: environ.o UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: convert.o UX:tsort: INFO: connection.o UX:tsort: INFO: results.o UX:tsort: INFO: parse.o UX:tsort: INFO: statement.o UX:tsort: INFO: bind.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: execute.o UX:tsort: INFO: environ.o UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: convert.o UX:tsort: INFO: connection.o UX:tsort: INFO: results.o UX:tsort: INFO: qresult.o UX:tsort: INFO: columninfo.o : libpsqlodbc.a cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26 Undefined first referenced symbol in file close socket.o strcat info.o getpwuidmisc.o atofconnection.o atoiinfo.o atolconvert.o malloc info.o labstuplelist.o strchr info.o ldexpf libm.so ldexpl libm.so fgets gpps.o strcmp info.o strstr info.o _lib_versionlibm.so strcasecmp convert.o _modf libm.so strcpy info.o memcpy convert.o strlen info.o __ctype convert.o strrchr results.o strtok info.o modff libm.so modfl libm.so timeconvert.o localtime convert.o multibyte_char_checkconvert.o __thr_errno libm.so getpid misc.o sprintf info.o setbuf misc.o inet_addr socket.o multibyte_strchrconvert.o strdup columninfo.o strncasecmp convert.o getuid misc.o check_client_encoding connection.o ldexp libm.so realloc info.o multibyte_init convert.o fclose gpps.o fopen misc.o strncat convert.o strncpy connection.o gethostbyname socket.o strncmp info.o sscanf connection.o vfprintfmisc.o freeinfo.o _write libm.so ilogb libm.so frexpl libm.so UX:ld: WARNING: Symbol referencing errors. rm -f libpsqlodbc.so.0 ln -s libpsqlodbc.so.0.26 libpsqlodbc.so.0 rm -f libpsqlodbc.so ln -s libpsqlodbc.so.0.26 libpsqlodbc.so Original Message On 3/22/01, 12:23:57 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman [EMAIL PROTECTED] writes: Does this mean it's eligible to be fixed for 7.1? We can talk about it anyway. Does removing the _fini alone make it work for you, or do we have to remove _init too? regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] (forw) Revised schedule for 4.3-RELEASE
FYI. - Forwarded message from Jordan Hubbard [EMAIL PROTECTED] - Sender: [EMAIL PROTECTED] From: Jordan Hubbard [EMAIL PROTECTED] Subject: Revised schedule for 4.3-RELEASE Date: Thu, 22 Mar 2001 12:04:09 -0800 Message-Id: [EMAIL PROTECTED] X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Hi folks, I've thought long and hard about this over the past week and I think we're going to need a bit more time to get 4-stable into the kind of shape I think we all *want* it to be in come release time. Now that people are really starting to ramp up and test the bits, we're getting some interesting reports and some of them may be indicative of issues which are rather severe. It's still too early to tell, but with the release date set for March 30th we also don't really have much time to find out or to fix any of the issues people are current identifying so, without further ado, here's my provisional revised schedule: March 26th: 4.3-RC1 April 2nd:4.3-RC2 April 10th: 4.3-RC3 April 15th: 4.3-RELEASE Why three RC (Release Candidate) builds rather than just one? Because it seems that people really tend to test the RCs more than the -stable snapshots, which lack ISO images and any real sense of collective effort behind them. If we break this into three checkpoints, each on a Monday, we have a full week for people to syncronize themselves on that RC and make sure that: a) Any bugs they reported in the previous week are gone and b) There are no new bugs they can find. By April 15th, tax day** here in the US, I think we'll be ready to create a very good 4.3-RELEASE! Thanks, - Jordan ** And I already filed mine, so nyah nyah nyah! :-) :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message - 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
using the following link, with the _init/_fini killed, works: cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o libpsqlodbc.so.0.26 SO, Peter, how do we fix the generated make file? Original Message On 3/22/01, 12:23:57 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman [EMAIL PROTECTED] writes: Does this mean it's eligible to be fixed for 7.1? We can talk about it anyway. Does removing the _fini alone make it work for you, or do we have to remove _init too? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
Peter, I'm not a GNU MAKE person, can you help here? LER Original Message On 3/22/01, 12:49:10 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman [EMAIL PROTECTED] writes: need to kill the _init too. Then we get other symbol issues, I think due to -Wl,z,text, but I'm not sure. Um. This suggests that the real problem is a completely wrong approach to linking the shared lib. On this evidence I'm not going to touch the _init/_fini ... looks more like you should be fooling with linker switches. 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])
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
and before you ask, the _init and _fini NEED to go away. LER Original Message On 3/22/01, 1:00:08 PM, Larry Rosenman [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : using the following link, with the _init/_fini killed, works: cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o libpsqlodbc.so.0.26 SO, Peter, how do we fix the generated make file? Original Message On 3/22/01, 12:23:57 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman [EMAIL PROTECTED] writes: Does this mean it's eligible to be fixed for 7.1? We can talk about it anyway. Does removing the _fini alone make it work for you, or do we have to remove _init too? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
My question is WHY are we using -Bsymbolic and/or -z text anyway? These options don't appear to buy us anything but grief on SVR[45] ELF systems.. The -lpq is NOT needed, that was my f*** up. LER Original Message On 3/22/01, 2:50:53 PM, Peter Eisentraut [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman writes: need to kill the _init too. Then we get other symbol issues, I think due to -Wl,z,text, but I'm not sure. These look to be due to the -Bsymbolic. Note they're only warnings, but you could really only tell by trying out the driver. I have a slight suspicion that -z text plus -Bsymbolic is an idiosyncratic combination, but I might be off. ar crs libpsqlodbc.a `lorder info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o | tsort` UX:tsort: WARNING: Cycle in data UX:tsort: INFO: results.o UX:tsort: INFO: parse.o UX:tsort: INFO: info.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: execute.o UX:tsort: INFO: environ.o UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: convert.o UX:tsort: INFO: connection.o UX:tsort: INFO: results.o UX:tsort: INFO: parse.o UX:tsort: INFO: statement.o UX:tsort: INFO: bind.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: execute.o UX:tsort: INFO: environ.o UX:tsort: INFO: dlg_specific.o UX:tsort: INFO: convert.o UX:tsort: INFO: connection.o UX:tsort: INFO: results.o UX:tsort: INFO: qresult.o UX:tsort: INFO: columninfo.o : libpsqlodbc.a cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o tuplelist.o dlg_specific.o -lm -Wl,-R/usr/local/pgsql/lib -o libpsqlodbc.so.0.26 Undefined first referenced symbol in file close socket.o strcat info.o getpwuidmisc.o atofconnection.o atoiinfo.o atolconvert.o malloc info.o labstuplelist.o strchr info.o ldexpf libm.so ldexpl libm.so fgets gpps.o strcmp info.o strstr info.o _lib_versionlibm.so strcasecmp convert.o _modf libm.so strcpy info.o memcpy convert.o strlen info.o __ctype convert.o strrchr results.o strtok info.o modff libm.so modfl libm.so timeconvert.o localtime convert.o multibyte_char_checkconvert.o __thr_errno libm.so getpid misc.o sprintf info.o setbuf misc.o inet_addr socket.o multibyte_strchrconvert.o strdup columninfo.o strncasecmp convert.o getuid misc.o check_client_encoding connection.o ldexp libm.so realloc info.o multibyte_init convert.o fclose gpps.o fopen misc.o strncat convert.o strncpy connection.o gethostbyname socket.o strncmp info.o sscanf connection.o vfprintfmisc.o freeinfo.o _write libm.so ilogb libm.so frexpl libm.so UX:ld: WARNING: Symbol referencing errors. rm -f libpsqlodbc.so.0 ln -s libpsqlodbc.so.0.26 libpsqlodbc.so.0 rm -f libpsqlodbc.so ln -s libpsqlodbc.so.0.26 libpsqlodbc.so Original Message On 3/22/01, 12:23:57 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
OK, will do. For the record: -z text In dynamic mode only, force a fatal error if any relocations against non-writable, allocatable sections remain. This is the default for IA-64 objects. I don't have a good way to test it yet, as the only ODBC client I have is Star Office which is a Linux binary, and I can't seem to get the unixODBC configuration to like it on the FreeBSD box. I guess this will have to wait for 7.2, since we are in Freeze, though. No biggie for me, just trying to help. I do think that the _init/_fini stuff should go away for NON-GCC platforms, though. Also, docs for UnixWare are at: http://uw7doc.sco.com/ or my local copy for my local system (accessable however): http://www.lerctr.org:457/ LER Original Message On 3/22/01, 3:38:59 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman [EMAIL PROTECTED] writes: My question is WHY are we using -Bsymbolic and/or -z text anyway? These options don't appear to buy us anything but grief on SVR[45] ELF systems.. I have no idea what -z text means to your linker, but if it has a -Bsymbolic option then it's a good bet that you need that. The ODBC driver contains some function names that duplicate names in the unixODBC driver manager. The driver's own references to these functions *must* be resolved to its own routines and not the manager's, else havoc ensues. But for some reason, the other way is the default on many platforms. Do not assume that you have this right just because the build succeeds. I found in testing on HPUX that not only could you build a wrongly linked driver, but it would actually load and connect. Only certain kinds of queries exhibited the problem. In short: better test it before you claim you have it fixed. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.
OK, it *IS* just a WARNING that the symbols are undefined. SO, can we get the _fini/_init stuff commented/taken out for 7.1? LER Original Message On 3/22/01, 3:38:59 PM, Tom Lane [EMAIL PROTECTED] wrote regarding Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. : Larry Rosenman [EMAIL PROTECTED] writes: My question is WHY are we using -Bsymbolic and/or -z text anyway? These options don't appear to buy us anything but grief on SVR[45] ELF systems.. I have no idea what -z text means to your linker, but if it has a -Bsymbolic option then it's a good bet that you need that. The ODBC driver contains some function names that duplicate names in the unixODBC driver manager. The driver's own references to these functions *must* be resolved to its own routines and not the manager's, else havoc ensues. But for some reason, the other way is the default on many platforms. Do not assume that you have this right just because the build succeeds. I found in testing on HPUX that not only could you build a wrongly linked driver, but it would actually load and connect. Only certain kinds of queries exhibited the problem. In short: better test it before you claim you have it fixed. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for platforms
* Tom Lane [EMAIL PROTECTED] [010321 21:29]: Tatsuo Ishii [EMAIL PROTECTED] writes: Tatsuo Ishii [EMAIL PROTECTED] writes: ! FATAL 2: ZeroFill(logfile 0 seg 1) failed: No such file or directory ! pqReadData() -- backend closed the channel unexpectedly. Is it possible you ran out of disk space? Probably not. The reason I was speculating that was that it seems pretty unlikely that a write() call could return ENOENT, as the above appears to suggest. I think that the errno = ENOENT value was not set by write(), but is leftover from the expected failure of BasicOpenFile earlier in XLogFileInit. Probably write() returned some value less than BLCKSZ but more than zero, and so did not set errno. Offhand the only reason I can think of for a write to a disk file to terminate after a partial transfer is a full disk. What do you think? What about hitting a quota? LER regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pgindent run?
* Bruce Momjian [EMAIL PROTECTED] [010321 22:11]: Are there any severely mis-indented files? There are some new contrib modules that are nowhere close to our indent conventions; also a good deal of foreign-key-related stuff in the parser that needs to be cleaned up. So we should run it. I've always felt that it'd be smarter to run pgindent at the start of a development cycle, not the end, but I've been unable to convince Bruce of that ... Hey, I am open to whatever people want to do. Just remember that we accumulate lots of patches/development during the slow time before development, and those patches become harder to apply. Peter E has some already. How about: 1) just AFTER release 2) just BEFORE Beta LER -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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 -- 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])
Re: [HACKERS] Call for platforms
* Thomas Lockhart [EMAIL PROTECTED] [010320 20:04]: OK, here is my current platform list taken from the -hackers list and from Vince's web page. I'm sure I've missed at least a few reports, but please confirm that platforms are actually running and passing regression tests with recent betas or the latest release candidate. If a platform you are running on is not listed, make sure it gets included! Platforms with reports for 7.0 risk being demoted to the "used to be supported list", and platforms with reports for only 6.5 are on a deathwatch, so be sure to speak up! Also, I've included names below to remind us who helped last time, but feel free to report even if your name is not already listed. FreeBSD 4.3-BETA (will be -RELEASE by the time we release) works too. I reported FreeBSD 4.[23]. LER I've separated out recent reports and put them at the end of the list. Thanks in advance. - Thomas AIX 4.3.2 RS6000 7.0 2000-04-05, Andreas Zeugswetter Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii NetBSD 1.4 arm32 7.0 2000-04-08, Patrick Welche NetBSD 1.4U x867.0 2000-03-26, Patrick Welche NetBSD m68k7.0 2000-04-10, Henry B. Hotz NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos SCO OpenServer 5 x86 6.5 1999-05-25, Andrew Merrill Solaris x867.0 2000-04-12, Marc Fournier Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) WinNT/Cygwin x86 7.0 2000-03-30, Daniel Horak BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane IBMS/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick LinuxPPC G37.1 2001-03-19, Tom Lane SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: elog with automatic file, line, and function
* Pete Forman [EMAIL PROTECTED] [010320 04:22]:
Larry Rosenman writes:
* Tom Lane [EMAIL PROTECTED] [010319 18:58]:
However, if the C99 spec has such a concept, they didn't use that name
for it ...
My C99 compiler (SCO, UDK FS 7.1.1b), defines the following:
Predefined names
The following identifiers are predefined as object-like macros:
__LINE__
The current line number as a decimal constant.
__FILE__
A string literal representing the name of the file being compiled.
__DATE__
The date of compilation as a string literal in the form ``Mmm dd
.''
__TIME__
The time of compilation, as a string literal in the form
``hh:mm:ss.''
__STDC__
The constant 1 under compilation mode -Xc, otherwise 0.
__USLC__
A positive integer constant; its definition signifies a USL C
compilation system.
Nothing for function that I can find.
It is called __func__ in C99 but it is not an object-like macro. The
difference is that it behaves as if it were declared thus.
static const char __func__[] = "function-name";
Those other identifiers can be used in this sort of way.
printf("Error in " __FILE__ " at line " __LINE__ "\n");
But you've got to do something like this for __func__.
printf("Error in %s\n", __func__);
I couldn't find it in the docs, but it is in the compiler.
Wierd.
I'll look more.
LER
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
[EMAIL PROTECTED] -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/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
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: AW: [HACKERS] Re: More on elog and error codes
Coming from an IBM Mainframe background, I'm used to ALL OS/Product messages having a message number, and a fat messages and codes book. I hope we can do that eventually. (maybe a database of the error numbers and codes?) LER Original Message On 3/20/01, 10:53:42 AM, Peter Eisentraut [EMAIL PROTECTED] wrote regarding Re: AW: [HACKERS] Re: More on elog and error codes: Zeugswetter Andreas SB writes: SQL9x specifies some error codes, with no particular numbering scheme other than negative numbers indicate a problem afaicr. Shouldn't we map to those where possible? Yes, it defines at least a few dozen char(5) error codes. These are hierarchical, grouped into Warnings and Errors, and have room for implementation specific message codes. Let's use those then to start with. Anyone got a good idea for a client API to this? I think we could just prefix the actual message with the error code, at least as a start. Since they're all fixed width the client could take them apart easily. I recall other RDBMS' (Oracle?) also having an error code before each message. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] ODBC/FreeBSD/LinuxEmulation/RPM?
Is there any way to get just the ODBC RPM to install with OUT installing the whole DB? I have a strange situation: StarOffice 5.2 (Linux) Running under FreeBSD Linux Emulation PG running NATIVE. I want the two to talk, using ODBC. How do I make this happen? 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] ODBC/FreeBSD/LinuxEmulation/RPM?
I figured that out, now to get the ODBC stuff totally right on the LINUX side of the box. Do we work with unixODBC or the other one? LER Original Message On 3/19/01, 1:44:02 PM, Alfred Perlstein [EMAIL PROTECTED] wrote regarding Re: [HACKERS] ODBC/FreeBSD/LinuxEmulation/RPM?: * Alfred Perlstein [EMAIL PROTECTED] [010319 11:27] wrote: * Larry Rosenman [EMAIL PROTECTED] [010319 10:35] wrote: Is there any way to get just the ODBC RPM to install with OUT installing the whole DB? I have a strange situation: StarOffice 5.2 (Linux) Running under FreeBSD Linux Emulation PG running NATIVE. I want the two to talk, using ODBC. How do I make this happen? rpm2cpio pg_rpmfile.rpm pg_rpmfile.cpio cpio -i pg_rpmfile.cpio tar xzvf pg_rpmfile.tgz Sorry, i was just waking up when I wrote this... the idea is to extract the rpm then just grab the required ODBC files. best of luck, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] elog with automatic file, line, and function
* Tom Lane [EMAIL PROTECTED] [010319 18:58]: Ian Lance Taylor [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: BTW, how does that work exactly? I assume it can't be a macro ... It's a macro just like __FILE__ and __LINE__ are macros. gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time (the latter is the demangled version of the function name when using C++). Now that I know the name, I can find it in the gcc docs, which clearly explain that these names are not macros ;-). The preprocessor would have a tough time making such a substitution. However, if the C99 spec has such a concept, they didn't use that name for it ... My C99 compiler (SCO, UDK FS 7.1.1b), defines the following: Predefined names The following identifiers are predefined as object-like macros: __LINE__ The current line number as a decimal constant. __FILE__ A string literal representing the name of the file being compiled. __DATE__ The date of compilation as a string literal in the form ``Mmm dd .'' __TIME__ The time of compilation, as a string literal in the form ``hh:mm:ss.'' __STDC__ The constant 1 under compilation mode -Xc, otherwise 0. __USLC__ A positive integer constant; its definition signifies a USL C compilation system. Nothing for function that I can find. LER regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
* Tom Lane [EMAIL PROTECTED] [010318 14:55]: Alfred Perlstein [EMAIL PROTECTED] writes: Just by making a thread call libc changes personality to use thread safe routines (I.E. add mutex locking). Use one thread feature, get the whole set...which may not be that bad. Actually it can be pretty bad. Locked bus cycles needed for mutex operations are very, very expensive, not something you want to do unless you really really need to do it. It'd be interesting to try to get some numbers about the actual cost of using a thread-aware libc, on platforms where there's a difference. Shouldn't be that hard to build a postgres executable with the proper library and run some benchmarks ... anyone care to try? I can get the code compiled, but don't have the skills to generate a test case worthy of anything LER regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: AW: Allowing WAL fsync to be done via O_SYNC
My UnixWare box runs Veritas' VXFS, and has Online-Data Manager installed. Documentation is available at http://www.lerctr.org:457/ There are MULTIPLE sync modes, and there are also hints an app can give to the FS. More info is available if you want. 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 US Original Message On 3/16/01, 9:11:51 AM, Thomas Lockhart [EMAIL PROTECTED] wrote regarding [HACKERS] Re: AW: Allowing WAL fsync to be done via O_SYNC: Okay ... we can fall back to O_FSYNC if we don't see either of the others. No problem. Any other weird cases out there? I think Andreas might've muttered something about AIX but I'm not sure now. You can safely use O_DSYNC on AIX, the only special on AIX is, that it does not make a speed difference to O_SYNC. This is imho because the jfs only needs one sync write to the jfs journal for meta info in eighter case (so that nobody misunderstands: both perform excellent). Hmm. Does everyone run jfs on AIX, or are there other file systems available? The same issue should be raised for Linux (at least): have we tried test cases with both journaling and non-journaling file systems? Perhaps the flag choice would be markedly different for the different options? - Thomas ---(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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Performance monitor signal handler
* Jan Wieck [EMAIL PROTECTED] [010316 16:35]: Jan Wieck wrote: Tom Lane wrote: Now this would put a pretty tight time constraint on the collector: fall more than 4K behind, you start losing data. I am not sure if a UDP socket would provide more buffering or not; anyone know? Looks like Linux has something around 16-32K of buffer space for UDP sockets. Just from eyeballing the fprintf(3) output of my destructively hacked postleprechaun. Just to get some evidence at hand - could some owners of different platforms compile and run the attached little C source please? (The program tests how much data can be stuffed into a pipe or a Sys-V message queue before the writer would block or get an EAGAIN error). My output on RedHat6.1 Linux 2.2.17 is: Pipe buffer is 4096 bytes Sys-V message queue buffer is 16384 bytes Seems Tom is (unfortunately) right. The pipe blocks at 4K. So a Sys-V message queue, with the ability to distribute messages from the collector to individual backends with kernel support via "mtype" is four times by unestimated complexity better here. What does your system say? I really never thought that Sys-V IPC is a good way to go at all. I hate it's incompatibility to the select(2) system call and all these OS/installation dependant restrictions. But I'm tempted to reevaluate it "for this case". Jan $ ./queuetest Pipe buffer is 32768 bytes Sys-V message queue buffer is 4096 bytes $ uname -a UnixWare lerami 5 7.1.1 i386 x86at SCO UNIX_SVR5 $ I think some of these are configurable... 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: [HACKERS] Performance monitor signal handler
* Larry Rosenman [EMAIL PROTECTED] [010316 20:47]: * Jan Wieck [EMAIL PROTECTED] [010316 16:35]: $ ./queuetest Pipe buffer is 32768 bytes Sys-V message queue buffer is 4096 bytes $ uname -a UnixWare lerami 5 7.1.1 i386 x86at SCO UNIX_SVR5 $ I think some of these are configurable... They both are. FIFOBLKSIZE and MSGMNB or some such kernel tunable. I can get more info if you need it. 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC
I'd actually vote for it to remain for a release or two or more, as we get more experience with stuff, the defaults may be different for different workloads. 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 US Original Message On 3/15/01, 2:46:20 PM, Bruce Momjian [EMAIL PROTECTED] wrote regarding Re: [HACKERS] Allowing WAL fsync to be done via O_SYNC: Bruce Momjian [EMAIL PROTECTED] writes: I later read Vadim's comment that fsync() of two blocks may be faster than two O_* writes, so I am now confused about the proper solution. However, I think we need to pick one and make it invisible to the user. Perhaps a compiler/config.h flag for testing would be a good solution. I believe that we don't know enough yet to nail down a hard-wired decision. Vadim's idea of preferring O_DSYNC if it appears to be different from O_SYNC is a good first cut, but I think we'd better make it possible to override that, at least for testing purposes. So I think it should be configurable at *some* level. I don't much care whether it's a config.h entry or a GUC variable. But consider this: we'll be more likely to get some feedback from the field (allowing us to refine the policy in future releases) if it is a GUC variable. Not many people will build two versions of the software, but people might take the trouble to play with a run-time configuration setting. Yes, I can imagine. Can we remove it once we know the answer? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Performance monitor
I don't believe that UnixWare will take the PS change without having ROOT. LER Original Message On 3/8/01, 3:54:31 PM, Peter Eisentraut [EMAIL PROTECTED] wrote regarding Re: [HACKERS] Performance monitor : Tom Lane writes: How many of our supported platforms actually have working ps-status code? (This is an honest question: I don't know.) BeOS, DG/UX, and Cygwin don't have support code, the rest *should* work. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] Re: int8 beta5 broken?
Working on it. Give me a couple of hours. LER -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 11:04 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Larry Rosenman Subject: Re: [HACKERS] Re: int8 beta5 broken? Olivier PRENANT [EMAIL PROTECTED] writes: Sorry to follow-up on my own post; int8 test passes if open-ssl is not used. That's difficult to believe, because int8.c doesn't include anything that even knows SSL exists. Larry, can you confirm this behavior? regards, tom lane
Re: [HACKERS] Re: int8 beta5 broken?
* Larry Rosenman [EMAIL PROTECTED] [010228 11:13]: Working on it. Give me a couple of hours. Olivier, How did you build OpenSSL? I get the following (I only have a static lib): cc -O -K inline -K PIC -I. -I../../../src/include -I/usr/local/include -I/usr/local/ssl/include -DFRONTEND -DSYSCONFDIR='"/usr/local/pgsql/etc"' -c -o wchar.o wchar.c ar crs libpq.a `lorder fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o dllist.o pqsignal.o wchar.o | tsort` UX:tsort: WARNING: Cycle in data UX:tsort: INFO: fe-connect.o UX:tsort: INFO: fe-auth.o UX:tsort: WARNING: Cycle in data UX:tsort: INFO: fe-exec.o UX:tsort: INFO: fe-misc.o UX:tsort: INFO: fe-connect.o : libpq.a cc -G -Wl,-z,text -Wl,-h,libpq.so.2 fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o pqexpbuffer.o dllist.o pqsignal.owchar.o -L/usr/local/lib -L/usr/local/ssl/lib -lssl -lcrypto -lresolv -lnsl -lsocket -Wl,-R/usr/local/pgsql/lib -o libpq.so.2.1 UX:ld: INFO: text relocations referenced from files: libssl.a(s23_meth.o) libssl.a(s23_srvr.o) libssl.a(s23_clnt.o) libssl.a(s23_lib.o) libssl.a(s23_pkt.o) libssl.a(t1_meth.o) libssl.a(t1_srvr.o) libssl.a(t1_clnt.o) libssl.a(t1_lib.o) libssl.a(t1_enc.o) libssl.a(ssl_lib.o) libssl.a(ssl_err2.o) libssl.a(ssl_cert.o) libssl.a(ssl_sess.o) libssl.a(ssl_ciph.o) libssl.a(ssl_algs.o) libssl.a(ssl_err.o) libssl.a(s2_srvr.o) libssl.a(s2_clnt.o) libssl.a(s2_lib.o) libssl.a(s2_enc.o) libssl.a(s2_pkt.o) libssl.a(s3_meth.o) libssl.a(s3_srvr.o) libssl.a(s3_clnt.o) libssl.a(s3_lib.o) libssl.a(s3_enc.o) libssl.a(s3_pkt.o) libssl.a(s3_both.o) libssl.a(ssl_rsa.o) libcrypto.a(cryptlib.o) libcrypto.a(mem.o) libcrypto.a(ex_data.o) libcrypto.a(md5_dgst.o) libcrypto.a(sha1dgst.o) libcrypto.a(hmac.o) libcrypto.a(fcrypt.o) libcrypto.a(bn_lib.o) libcrypto.a(rsa_lib.o) libcrypto.a(rsa_sign.o) libcrypto.a(dsa_vrf.o) libcrypto.a(dsa_sign.o) libcrypto.a(dh_key.o) libcrypto.a(dh_lib.o) libcrypto.a(buffer.o) libcrypto.a(bio_lib.o) libcrypto.a(bss_file.o) libcrypto.a(bss_sock.o) libcrypto.a(bf_buff.o) libcrypto.a(b_print.o) libcrypto.a(stack.o) libcrypto.a(lhash.o) libcrypto.a(rand_lib.o) libcrypto.a(err.o) libcrypto.a(err_all.o) libcrypto.a(o_names.o) libcrypto.a(obj_dat.o) libcrypto.a(obj_lib.o) libcrypto.a(obj_err.o) libcrypto.a(digest.o) libcrypto.a(evp_enc.o) libcrypto.a(e_des.o) libcrypto.a(e_idea.o) libcrypto.a(e_des3.o) libcrypto.a(e_rc4.o) libcrypto.a(names.o) libcrypto.a(e_rc2.o) libcrypto.a(m_md2.o) libcrypto.a(m_md5.o) libcrypto.a(m_sha1.o) libcrypto.a(m_dss1.o) libcrypto.a(p_sign.o) libcrypto.a(p_verify.o) libcrypto.a(p_lib.o) libcrypto.a(evp_err.o) libcrypto.a(e_null.o) libcrypto.a(evp_lib.o) libcrypto.a(evp_pbe.o) libcrypto.a(a_object.o) libcrypto.a(a_dup.o) libcrypto.a(x_sig.o) libcrypto.a(x_name.o) libcrypto.a(x_x509.o) libcrypto.a(x_x509a.o) libcrypto.a(d2i_r_pr.o) libcrypto.a(i2d_r_pr.o) libcrypto.a(d2i_pr.o) libcrypto.a(i2d_dhp.o) libcrypto.a(d2i_dhp.o) libcrypto.a(asn1_lib.o) libcrypto.a(asn1_err.o) libcrypto.a(evp_asn1.o) libcrypto.a(pem_all.o) libcrypto.a(pem_err.o) libcrypto.a(x509_d2.o) libcrypto.a(x509_cmp.o) libcrypto.a(x509_obj.o) libcrypto.a(x509_vfy.o) libcrypto.a(x509_err.o) libcrypto.a(x509_ext.o) libcrypto.a(x509type.o) libcrypto.a(x509_lu.o) libcrypto.a(x_all.o) libcrypto.a(x509_trs.o) libcrypto.a(by_file.o) libcrypto.a(by_dir.o) libcrypto.a(v3_lib.o) libcrypto.a(v3err.o) libcrypto.a(v3_alt.o) libcrypto.a(v3_skey.o) libcrypto.a(v3_akey.o) libcrypto.a(v3_pku.o) libcrypto.a(v3_enum.o) libcrypto.a(v3_sxnet.o) libcrypto.a(v3_cpols.o) libcrypto.a(v3_crld.o) libcrypto.a(v3_purp.o) libcrypto.a(v3_info.o) libcrypto.a(conf_err.o) libcrypto.a(pkcs7err.o) libcrypto.a(pk12err.o) libcrypto.a(comp_lib.o) libcrypto.a(mem_dbg.o) libcrypto.a(cpt_err.o) libcrypto.a(md2_dgst.o) libcrypto.a(md5_one.o) libcrypto.a(set_key.o) libcrypto.a(ecb_enc.o) libcrypto.a(ecb3_enc.o) libcrypto.a(cfb64enc.o) libcrypto.a(cfb64ede.o) libcrypto.a(ofb64ede.o) libcrypto.a(ofb64enc.o) libcrypto.a(des_enc.o) libcrypto.a(fcrypt_b.o) libcrypto.a(rc2_ecb.o) libcrypto.a(rc2_skey.o) libcrypto.a(rc2_cbc.o) libcrypto.a(rc2cfb64.o) libcrypto.a(rc2ofb64.o) libcrypto.a(rc4_skey.o) libcrypto.a(i_cbc.o) libcrypto.a(i_cfb64.o) libcrypto.a(i_ofb64.o) libcrypto.a(i_ecb.o) libcrypto.a(bn_exp.o) libcrypto.a(bn_ctx.o) libcrypto.a(bn_mul.o) libcrypto.a(bn_rand.o) libcrypto.a(bn_word.o) libcrypto.a(bn_blind.o) libcrypto.a(bn_gcd.o) libcrypto.a(bn_err.o) libcrypto.a(bn_sqr.o) libcrypto.a(bn_asm.o) libcrypto.a(bn_recp.o) libcrypto.a(bn_mont.o) libcrypto.a(rsa_eay.o) libcrypto.a(rsa_err.o) libcrypto.a(rsa_pk1.o) libcrypto.a(rsa_ssl.o) libcrypto.a(rsa_none.o) libcrypto.a(rsa_oaep.o) libcrypto.a(dsa_lib.o) libcrypto.a(dsa_asn1.o) libcrypto.a(dsa_err.o) libcrypto.a(dsa_ossl.o) libcrypto.a(dh_err.o) libcrypto.a(dso_err.o) libcrypto.a(buf_err.o) libcrypto.a(bio_err.o) libcrypto.a(md_rand.o) libcrypto.a(rand_err.o) libcrypto.a(rand_win.o) libcrypto.a(evp_pkey.o) l
Re: [HACKERS] beta5 and unixware 711
* Olivier PRENANT [EMAIL PROTECTED] [010227 13:30]: Hi all, I've been trying to play with beta5 today on unixware 711. I have 2 problems: 1) enabling --with-tcl yields to link errors on bin/pgtclsh and interfaces/pl/tcl because Makefile insists on linking with libtcl7.6.0 instead on libtcl7.6 With the Skunkware packages installed, it's fine here. 2) enabling --with-openssl causes a compilation error on src/backend/libpq/crypt.c because of multiply defined symbol des_encrypt This is an OpenSSL error. We need to get THEIR attention LER Regards, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- 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
Re: [HACKERS] beta5 and unixware 711
* Olivier PRENANT [EMAIL PROTECTED] [010227 15:00]: On Tue, 27 Feb 2001, Larry Rosenman wrote: * Olivier PRENANT [EMAIL PROTECTED] [010227 13:30]: Hi all, I've been trying to play with beta5 today on unixware 711. I have 2 problems: 1) enabling --with-tcl yields to link errors on bin/pgtclsh and interfaces/pl/tcl because Makefile insists on linking with libtcl7.6.0 instead on libtcl7.6 With the Skunkware packages installed, it's fine here. You mean V802?? I had the same problems... lerami% ldd ~postgres/bin/pgtclsh /usr/local/pgsql/bin/pgtclsh needs: libpgtcl.so.2 = /usr/local/pgsql/lib/libpgtcl.so.2 libpq.so.2 = /usr/local/pgsql/lib/libpq.so.2 libtcl8.2.so = /usr/local/lib/libtcl8.2.so /usr/lib/libdl.so.1 /usr/lib/libsocket.so.2 /usr/lib/libm.so.1 /usr/local/lib/libz.so.1 /usr/lib/libresolv.so.2 /usr/lib/libnsl.so.1 /usr/local/lib/libreadline.so.3 /usr/lib/libc.so.1 lerami% Here is my config input: CC=cc CXX=CC ./configure --prefix=/usr/local/pgsql --enable-syslog \ --with-CXX --with-perl --enable-multibyte --enable-cassert \ --with-includes=/usr/local/include --with-libs=/usr/local/lib \ --with-tcl --with-tclconfig=/usr/local/lib \ --with-tkconfig=/usr/local/lib --enable-locale --with-python 2) enabling --with-openssl causes a compilation error on src/backend/libpq/crypt.c because of multiply defined symbol des_encrypt This is an OpenSSL error. We need to get THEIR attention In the mean time, is there something I can do (apart from disbling ssl)? I would remove the des_encrypt from openSSL's des.h. Let me know if that works (I haven't tried). LER Regards, LER Regards, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Peter Eisentraut [EMAIL PROTECTED] [010221 16:09]: Tom Lane writes: Deleting files in the install directory during installation is very inappropriate. At least let's try to get rid of it for 7.2. I don't like it much either, but I agree with Larry that it's an essential transition step for now. Perhaps we can remove it again in 7.2 or 7.3 or so. I doubt that it ever really worked, or could work, to install a new version over an old one without deleting the old one first. This here is just one problem. We can't be making these funny workarounds every time the set of installed user visible files changes. For example, if an older version had a header file that the new version doesn't have, then user code that includes this file will still be silently broken. THIS CHANGED WITHIN A BETA CYCLE. THAT SHOULD HAVE WORKED. LER -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ -- 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
Re: [HACKERS] beta5 ...
* Lamar Owen [EMAIL PROTECTED] [010221 16:36]: Vince Vielhaber wrote: the things Lamar and Peter also mentioned. Note: I'm probably 450 messagees behind due to a 2 day dsl outage; I may have missed some of the conversation. Some messages trickled in, the rest flooded in over night. I may be nearing the time for incoming mail folders :) Join the club. I have just finished configuring my Netscape e-mail for incoming folders -- _important_ direct e-mails (having to to with my actual job) were getting lost in and amongst the various lists I am a member of. I get around 600 e-mails per day on fifteen or so different mailing lists (the ones at PostgreSQL.org, a half dozen at Broadcast.net, Bugtraq/Linux-alert/RedHat-announce, redhat-beta, AOLserver/OpenNSD/OpenACS, and a handful of Linux announce lists, unixODBC, CERT, plus all of our Internet listeners). Netscapes filters are a lifesaver! Of course, there are other more capable packages out there, but Netscape works the same on Win9x and Linux, both of which are in use on my notebook. I have to keep up, or the e-mail flood after a couple of days is just about unbearable. slocal/procmail/mutt on a Unix Box makes it easier. My Mailing list stuff gets filtered off. LER -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -- 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
RE: [HACKERS] PHP 4.0.4pl1 / Beta 5
but the changes in the include structure force us to. If someone includes the old ones that aren't supposed to be there, we cause non-obvious compile errors. LER -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 21, 2001 10:56 AM To: Larry Rosenman Cc: Tom Lane; Sascha Schumann; PostgreSQL Hackers List; Bruce Momjian Subject: Re: [HACKERS] PHP 4.0.4pl1 / Beta 5 Larry Rosenman writes: AND make sure we nuke any OLD version in $(destdir)/include... Which will cause a file not found vs. compile errors based on redeclares...? Deleting files in the install directory during installation is very inappropriate. At least let's try to get rid of it for 7.2. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: beta5 ...
* Thomas Lockhart [EMAIL PROTECTED] [010220 10:51]: Would there be any value in setting up a project on sourceforge to make use of their compile farm? I know that it doesn't cover all platforms, but it would perhaps be a start to mechanical compile and regression testing. I haven't looked at the platforms available in the compile farm recently, but afaik regression coverage for over half a dozen platforms already happens without (extra) effort: Tom Lane has three or more platforms, I've got Linux, Bruce has BSDI, Marc has FreeBSD, we have some active W32 developers, etc etc. I have a UnixWare 7.1.1 box I run PG on What would SF add to this mix? - Thomas -- 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Larry Rosenman [EMAIL PROTECTED] [010219 15:55]: * Larry Rosenman [EMAIL PROTECTED] [010219 15:45]: * Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] writes: I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. If we do that, no one will ever fix their code. Moreover, such an approach would conflict with the install-all-headers option... How about a BIG warning in the INSTALL doc, then? AND make sure we nuke any OLD version in $(destdir)/include... Which will cause a file not found vs. compile errors based on redeclares...? Thanks for killing the old versions. Now what do we do re PHP with releases 4.0.4pl1 and earlier which now won't compile against 7.1beta5 and later? I think we need to do SOMETHING LER 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 -- 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [010219 01:37]: On Sun, 18 Feb 2001, Larry Rosenman wrote: * Bruce Momjian [EMAIL PROTECTED] [010218 22:25]: Just shoot it over to the PHP folks. Seems they are already on top if it. I don't want to work around their normal system unless necessary. Their stuff seems to sit forever. I put it in the BugDB. The problem here is that we don't plan to release 4.0.5 during the next month. I don't know the exact timeframe for the release of PostgreSQL 7.0.1, but regular releases of PostgreSQL/PHP won't compile together for at least some time. That is rather frustating for the end-user and will delay the adoption of the new PostgreSQL release. I don't believe you will break if that patch is applied now. I don't have a 7.0 handy to compile against, but I can pull one if necessary. I believe it was an error for PHP to #include postgres.h at all. Comments from other -hackers? I have a couple of other UnixWare issues that have sort of languished... I found one report which is related to UnixWare's broken system libraries (#8441). I'll look into working around that later. If there are others, please point me into their direction. That's the one I was refering to. I submitted it when 4.0.4 came out, and it didn't even draw a comment till now Thanks! (The other one was the libtool patch which Rasmus did commit). 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [010219 07:42]: I don't believe you will break if that patch is applied now. InvalidOid is not defined otherwise. aha. Ok. PG-Hackers: Can we include a Dummy or #warning postgres.h in 7.1? I.E.: #ifndef _POSTGRES_H #define _POSTGRES_H #warning Client Code should not include postgres.h #endif - Sascha -- 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Sascha Schumann [EMAIL PROTECTED] [010219 10:57]: AFAIK there is no need for you to be including postgres.h in *any* Postgres release --- it's supposed to be an internal header file, not something that client applications need. Try it with just /home/sas/src/php4/ext/pgsql/pgsql.c: In function `php_if_pg_getlastoid': /home/sas/src/php4/ext/pgsql/pgsql.c:1260: `InvalidOid' undeclared (first use in this function) /home/sas/src/php4/ext/pgsql/pgsql.c:1260: (Each undeclared identifier is reported only once /home/sas/src/php4/ext/pgsql/pgsql.c:1260: for each function it appears in.) InvalidOid is used to check the return value of PQoidValue(). src/interfaces/libpq/fe-exec.c:PQoidValue() can return InvalidOid, so this appears like a legitimate use to me. Feel free to correct me though, I have not used the C fe before. I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. This is a PROBLEM. LER - Sascha -- 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] writes: I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. If we do that, no one will ever fix their code. Moreover, such an approach would conflict with the install-all-headers option... How about a BIG warning in the INSTALL doc, then? 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Larry Rosenman [EMAIL PROTECTED] [010219 15:45]: * Tom Lane [EMAIL PROTECTED] [010219 15:43]: Larry Rosenman [EMAIL PROTECTED] writes: I still think we need a dummy postgres.h in $(destdir)/include to catch others using it this release. PHP 4.0.4pl1 and earlier will *BREAK* unless we do. If we do that, no one will ever fix their code. Moreover, such an approach would conflict with the install-all-headers option... How about a BIG warning in the INSTALL doc, then? AND make sure we nuke any OLD version in $(destdir)/include... Which will cause a file not found vs. compile errors based on redeclares...? 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
Re: [HACKERS] Re: [BUGS] Turkish locale bug
* Tom Lane [EMAIL PROTECTED] [010219 21:02]:
Larry Rosenman [EMAIL PROTECTED] writes:
What about EBCDIC (IBM MainFrame, I.E. Linux on S/390, Z/390).
Right, that was what I meant about not wanting to hardwire assumptions
about ASCII.
We could instead code it as
if (isupper(ch))
ch = ch + ('a' - 'A');
what about:
if (isupper(ch) isalpha(ch))
ch = ch + ('a' - 'A');
?
or does that break somewhere?
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
[HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
PHP 4.0.4pl1 Build dies with current CVS: Making all in pgsql gmake[2]: Entering directory `/home/ler/php/ext/pgsql' gmake[3]: Entering directory `/home/ler/php/ext/pgsql' /bin/sh /home/ler/php/libtool --silent --mode=compile cc -Xb -I. -I/home/ler/php/ext/pgsql -I/home/ler/php/main -I/home/ler/php -I/usr/internet/apache/include -I/home/ler/php/Zend -I/usr/local/ssl/include -I/usr/local/include -I/home/ler/php/ext/xml/expat/xmltok -I/home/ler/php/ext/xml/expat/xmlparse -I/home/ler/php/TSRM -I/usr/local/pgsql/include -DNDEBUG -DUW=700 -DUSE_HSREGEX -DUSE_EXPAT -DXML_BYTE_ORDER=12 -O -c pgsql.c UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 53: typedef redeclared: regproc UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 54: typedef redeclared: RegProcedure UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 69: (struct) tag redeclared: varlena UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 87: identifier redeclared: bytea UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 88: identifier redeclared: text UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 89: identifier redeclared: BpChar UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 90: identifier redeclared: VarChar UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 171: typedef redeclared: int2vector UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 172: typedef redeclared: oidvector UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 179: (union) tag redeclared: nameData UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 182: identifier redeclared: NameData UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 183: identifier redeclared: Name UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 192: typedef redeclared: TransactionId UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 196: typedef redeclared: CommandId gmake[3]: *** [pgsql.lo] Error 1 gmake[3]: Leaving directory `/home/ler/php/ext/pgsql' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/ler/php/ext/pgsql' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/ler/php/ext' gmake: *** [all-recursive] Error 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
(forw) (forw) Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
OK, I found it. PHP was including postgres.h (which we no longer install, so we were picking up a Feb 7 version). Changing php's ext/pgsql/php_pgsql.h to #include postgres_fe.h fixes it. This is a gotcha for people following CVS or not cleaning out the $(DESTDIR)/include directory I'll submit a patch to the PHP folk. LER - Forwarded message from Larry Rosenman [EMAIL PROTECTED] - From: Larry Rosenman [EMAIL PROTECTED] Subject: (forw) Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS Date: Sun, 18 Feb 2001 14:50:32 -0600 Message-ID: [EMAIL PROTECTED] User-Agent: Mutt/1.3.15i X-Mailer: Mutt http://www.mutt.org/ To: PostgreSQL Hackers List [EMAIL PROTECTED], [EMAIL PROTECTED], Peter Eisentraut [EMAIL PROTECTED] Re-Sent due to bounce from ftp.postgresql.org - Forwarded message from Larry Rosenman [EMAIL PROTECTED] - From: Larry Rosenman [EMAIL PROTECTED] Subject: Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS Date: Sun, 18 Feb 2001 14:41:33 -0600 Message-ID: [EMAIL PROTECTED] User-Agent: Mutt/1.3.15i X-Mailer: Mutt http://www.mutt.org/ To: PostgreSQL Hackers List [EMAIL PROTECTED] * Larry Rosenman [EMAIL PROTECTED] [010218 14:19]: PHP 4.0.4pl1 Build dies with current CVS: Making all in pgsql gmake[2]: Entering directory `/home/ler/php/ext/pgsql' gmake[3]: Entering directory `/home/ler/php/ext/pgsql' /bin/sh /home/ler/php/libtool --silent --mode=compile cc -Xb -I. -I/home/ler/php/ext/pgsql -I/home/ler/php/main -I/home/ler/php -I/usr/internet/apache/include -I/home/ler/php/Zend -I/usr/local/ssl/include -I/usr/local/include -I/home/ler/php/ext/xml/expat/xmltok -I/home/ler/php/ext/xml/expat/xmlparse -I/home/ler/php/TSRM -I/usr/local/pgsql/include -DNDEBUG -DUW=700 -DUSE_HSREGEX -DUSE_EXPAT -DXML_BYTE_ORDER=12 -O -c pgsql.c UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 53: typedef redeclared: regproc UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 54: typedef redeclared: RegProcedure UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 69: (struct) tag redeclared: varlena UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 87: identifier redeclared: bytea UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 88: identifier redeclared: text UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 89: identifier redeclared: BpChar UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 90: identifier redeclared: VarChar UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 171: typedef redeclared: int2vector UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 172: typedef redeclared: oidvector UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 179: (union) tag redeclared: nameData UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 182: identifier redeclared: NameData UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 183: identifier redeclared: Name UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 192: typedef redeclared: TransactionId UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 196: typedef redeclared: CommandId gmake[3]: *** [pgsql.lo] Error 1 gmake[3]: Leaving directory `/home/ler/php/ext/pgsql' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/ler/php/ext/pgsql' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/ler/php/ext' gmake: *** [all-recursive] Error 1 $ more info, courtesy gcc: $ sh x gcc: unrecognized option `-KPIC' In file included from php_pgsql.h:32, from pgsql.c:29: /usr/local/pgsql/include/postgres.h:53: redefinition of `regproc' /usr/local/pgsql/include/c.h:312: `regproc' previously declared here /usr/local/pgsql/include/postgres.h:54: redefinition of `RegProcedure' /usr/local/pgsql/include/c.h:313: `RegProcedure' previously declared here /usr/local/pgsql/include/postgres.h:69: redefinition of `struct varlena' /usr/local/pgsql/include/postgres.h:87: redefinition of `bytea' /usr/local/pgsql/include/c.h:354: `bytea' previously declared here /usr/local/pgsql/include/postgres.h:88: redefinition of `text' /usr/local/pgsql/include/c.h:355: `text' previously declared here /usr/local/pgsql/include/postgres.h:89: redefinition of `BpChar' /usr/local/pgsql/include/c.h:356: `BpChar' previously declared here /usr/local/pgsql/include/postgres.h:90: redefinition of `VarChar' /usr/local/pgsql/include/c.h:357: `VarChar' previously declared here /usr/local/pgsql/include/postgres.h:171: redefinition of `int2vector' /usr/local/pgsql/include/c.h:363: `int2vector' previously declared here /usr/local/pgsql/include/postgres.h:172: redefinition of `oidvector' /usr/local/pgsql/include/c.h:364: `oidvector' previously declared here /usr/local/pgsql/include/postgres.
(forw) Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
Re-Sent due to bounce from ftp.postgresql.org - Forwarded message from Larry Rosenman [EMAIL PROTECTED] - From: Larry Rosenman [EMAIL PROTECTED] Subject: Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS Date: Sun, 18 Feb 2001 14:41:33 -0600 Message-ID: [EMAIL PROTECTED] User-Agent: Mutt/1.3.15i X-Mailer: Mutt http://www.mutt.org/ To: PostgreSQL Hackers List [EMAIL PROTECTED] * Larry Rosenman [EMAIL PROTECTED] [010218 14:19]: PHP 4.0.4pl1 Build dies with current CVS: Making all in pgsql gmake[2]: Entering directory `/home/ler/php/ext/pgsql' gmake[3]: Entering directory `/home/ler/php/ext/pgsql' /bin/sh /home/ler/php/libtool --silent --mode=compile cc -Xb -I. -I/home/ler/php/ext/pgsql -I/home/ler/php/main -I/home/ler/php -I/usr/internet/apache/include -I/home/ler/php/Zend -I/usr/local/ssl/include -I/usr/local/include -I/home/ler/php/ext/xml/expat/xmltok -I/home/ler/php/ext/xml/expat/xmlparse -I/home/ler/php/TSRM -I/usr/local/pgsql/include -DNDEBUG -DUW=700 -DUSE_HSREGEX -DUSE_EXPAT -DXML_BYTE_ORDER=12 -O -c pgsql.c UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 53: typedef redeclared: regproc UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 54: typedef redeclared: RegProcedure UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 69: (struct) tag redeclared: varlena UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 87: identifier redeclared: bytea UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 88: identifier redeclared: text UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 89: identifier redeclared: BpChar UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 90: identifier redeclared: VarChar UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 171: typedef redeclared: int2vector UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 172: typedef redeclared: oidvector UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 179: (union) tag redeclared: nameData UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 182: identifier redeclared: NameData UX:acomp: ERROR: "/usr/local/pgsql/include/postgres.h", line 183: identifier redeclared: Name UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 192: typedef redeclared: TransactionId UX:acomp: WARNING: "/usr/local/pgsql/include/postgres.h", line 196: typedef redeclared: CommandId gmake[3]: *** [pgsql.lo] Error 1 gmake[3]: Leaving directory `/home/ler/php/ext/pgsql' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/home/ler/php/ext/pgsql' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/ler/php/ext' gmake: *** [all-recursive] Error 1 $ more info, courtesy gcc: $ sh x gcc: unrecognized option `-KPIC' In file included from php_pgsql.h:32, from pgsql.c:29: /usr/local/pgsql/include/postgres.h:53: redefinition of `regproc' /usr/local/pgsql/include/c.h:312: `regproc' previously declared here /usr/local/pgsql/include/postgres.h:54: redefinition of `RegProcedure' /usr/local/pgsql/include/c.h:313: `RegProcedure' previously declared here /usr/local/pgsql/include/postgres.h:69: redefinition of `struct varlena' /usr/local/pgsql/include/postgres.h:87: redefinition of `bytea' /usr/local/pgsql/include/c.h:354: `bytea' previously declared here /usr/local/pgsql/include/postgres.h:88: redefinition of `text' /usr/local/pgsql/include/c.h:355: `text' previously declared here /usr/local/pgsql/include/postgres.h:89: redefinition of `BpChar' /usr/local/pgsql/include/c.h:356: `BpChar' previously declared here /usr/local/pgsql/include/postgres.h:90: redefinition of `VarChar' /usr/local/pgsql/include/c.h:357: `VarChar' previously declared here /usr/local/pgsql/include/postgres.h:171: redefinition of `int2vector' /usr/local/pgsql/include/c.h:363: `int2vector' previously declared here /usr/local/pgsql/include/postgres.h:172: redefinition of `oidvector' /usr/local/pgsql/include/c.h:364: `oidvector' previously declared here /usr/local/pgsql/include/postgres.h:179: redefinition of `union nameData' /usr/local/pgsql/include/postgres.h:182: redefinition of `NameData' /usr/local/pgsql/include/c.h:375: `NameData' previously declared here /usr/local/pgsql/include/postgres.h:183: redefinition of `Name' /usr/local/pgsql/include/c.h:376: `Name' previously declared here /usr/local/pgsql/include/postgres.h:192: redefinition of `TransactionId' /usr/local/pgsql/include/c.h:315: `TransactionId' previously declared here /usr/local/pgsql/include/postgres.h:196: redefinition of `CommandId' /usr/local/pgsql/include/c.h:319: `CommandId' previously declared here $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1
Re: (forw) (forw) Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
* Tom Lane [EMAIL PROTECTED] [010218 16:54]: Larry Rosenman [EMAIL PROTECTED] writes: OK, I found it. PHP was including postgres.h (which we no longer install, so we were picking up a Feb 7 version). Changing php's ext/pgsql/php_pgsql.h to #include postgres_fe.h fixes it. Hm. Should php be including either one? I would have been in less hurry to invent a new file if I had thought that client apps were including postgres.h ... hmm. It include libpq-fe.h as well. 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
Re: (forw) (forw) Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
* Tom Lane [EMAIL PROTECTED] [010218 16:54]: Larry Rosenman [EMAIL PROTECTED] writes: OK, I found it. PHP was including postgres.h (which we no longer install, so we were picking up a Feb 7 version). Changing php's ext/pgsql/php_pgsql.h to #include postgres_fe.h fixes it. Hm. Should php be including either one? I would have been in less hurry to invent a new file if I had thought that client apps were including postgres.h ... Interestingly, leaving out postgres_fe.h works as well. I'll update my bug report w/php to delete that line altogether. 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
Re: (forw) (forw) Re: [HACKERS] PHP 4.0.4pl1 BUILD: BUSTED WITH CURRENT CVS
* Tom Lane [EMAIL PROTECTED] [010218 16:54]: Larry Rosenman [EMAIL PROTECTED] writes: OK, I found it. PHP was including postgres.h (which we no longer install, so we were picking up a Feb 7 version). Changing php's ext/pgsql/php_pgsql.h to #include postgres_fe.h fixes it. Hm. Should php be including either one? I would have been in less hurry to invent a new file if I had thought that client apps were including postgres.h ... Updated to not include either postgres.h or postgres_fe.h FYI, bug # in PHP's DB is 9328. 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
[HACKERS] PHP needs to only include postgres_fe.h now...
Starting with PostgreSQL 7.1beta5 (or current CVS), PHP's pgsql extension needs to only include postgres_fe.h to compile. Here is a patch: Index: php_pgsql.h === RCS file: /cvsroot/php/ext/pgsql/php_pgsql.h,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 php_pgsql.h *** php_pgsql.h 2000/12/23 23:05:41 1.1.1.2 --- php_pgsql.h 2001/02/18 21:15:45 *** *** 29,35 #ifdef PHP_PGSQL_PRIVATE #undef SOCKET_SIZE_TYPE ! #include postgres.h #include libpq-fe.h #ifdef PHP_WIN32 --- 29,35 #ifdef PHP_PGSQL_PRIVATE #undef SOCKET_SIZE_TYPE ! #include postgres_fe.h #include libpq-fe.h #ifdef PHP_WIN32 -- 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Bruce Momjian [EMAIL PROTECTED] [010218 21:23]: [ Charset ISO-8859-1 unsupported, converting... ] I sure hope it gets more attention than some of the other PHP PostgreSQL bugs.. I don't mean to trash anyone here but the pg_connect problem has been around since 4.0.1 and has yet to be addressed. One of our programmers is taking a look at that one but he's not been able to fix it yet. I have worked with Thies on getting persistent connections to work better. If there are any PostgreSQL problems with PHP, I recommend sending something to him as he is focused on PostgreSQL recently. Can you point him at today's fun? Bug#9328 in PHP's bug DB. 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
Re: [HACKERS] PHP 4.0.4pl1 / Beta 5
* Bruce Momjian [EMAIL PROTECTED] [010218 22:25]: Just shoot it over to the PHP folks. Seems they are already on top if it. I don't want to work around their normal system unless necessary. Their stuff seems to sit forever. I put it in the BugDB. I have a couple of other UnixWare issues that have sort of languished... Your call Though... * Bruce Momjian [EMAIL PROTECTED] [010218 21:23]: [ Charset ISO-8859-1 unsupported, converting... ] I sure hope it gets more attention than some of the other PHP PostgreSQL bugs.. I don't mean to trash anyone here but the pg_connect problem has been around since 4.0.1 and has yet to be addressed. One of our programmers is taking a look at that one but he's not been able to fix it yet. I have worked with Thies on getting persistent connections to work better. If there are any PostgreSQL problems with PHP, I recommend sending something to him as he is focused on PostgreSQL recently. Can you point him at today's fun? Bug#9328 in PHP's bug DB. 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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- 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
Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
* Tom Lane [EMAIL PROTECTED] [010216 22:49]: "Schmidt, Peter" [EMAIL PROTECTED] writes: So, is it OK to use commit_delay=0? Certainly. In fact, I think that's about to become the default ;-) I have now experimented with several different platforms --- HPUX, FreeBSD, and two considerably different strains of Linux --- and I find that the minimum delay supported by select(2) is 10 or more milliseconds on all of them, as much as 20 msec on some popular platforms. Try it yourself (my test program is attached). Thus, our past arguments about whether a few microseconds of delay before commit are a good idea seem moot; we do not have any portable way of implementing that, and a ten millisecond delay for commit is clearly Not Good. regards, tom lane Here is another one. UnixWare 7.1.1 on a P-III 500 256 Meg Ram: $ cc -o tgl.test -O tgl.test.c $ time ./tgl.test 0 real0m0.01s user0m0.01s sys 0m0.00s $ time ./tgl.test 1 real0m10.01s user0m0.00s sys 0m0.01s $ time ./tgl.test 2 real0m10.01s user0m0.00s sys 0m0.00s $ time ./tgl.test 3 real0m10.11s user0m0.00s sys 0m0.01s $ uname -a UnixWare lerami 5 7.1.1 i386 x86at SCO UNIX_SVR5 $ -- 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
Re: [HACKERS] WAL and commit_delay
* Bruce Momjian [EMAIL PROTECTED] [010217 14:46]: Right now the WAL preallocation code (XLogFileInit) is not good enough because it does lseek to the 16MB position and then writes 1 byte there. On an implementation that supports holes in files (which is most Unixen) that doesn't cause physical allocation of the intervening space. We'd have to actually write zeroes into all 16MB to ensure the space is allocated ... but that's just a couple more lines of code. Are OS's smart enough to not allocate zero-written blocks? Do we need to write non-zeros? I don't believe so. writing Zeros is valid. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- 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
[HACKERS] python build/Current CVS/UnixWare
In the current CVS, the PYTHON build sets LDSHARED to ld -G, not cc -G. It passes -Wl,-h,... to the ld command, and breaks. ALL shared library builds on UnixWare should use cc -G or CC -g as appropriate. I don't see right off where this is set. Peter E, can you fix? Thanks! -- 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
[HACKERS] RE: python build/Current CVS/UnixWare
I submitted a bug to their SourceForge Bug List. Thanks! LER -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 12:34 PM To: Larry Rosenman Cc: PostgreSQL Hackers List Subject: Re: python build/Current CVS/UnixWare Larry Rosenman writes: In the current CVS, the PYTHON build sets LDSHARED to ld -G, not cc -G. It passes -Wl,-h,... to the ld command, and breaks. ALL shared library builds on UnixWare should use cc -G or CC -g as appropriate. I have arranged for the -Wl,-h to be left out in the Python build. The ld vs cc thing you have to take up with the Python folks. I'm not convinced their infrastructure works too well. For example, we might have to pull the same kludge as we do for the Perl interface build on some platforms. Eventually we might be able to write our own rules for this and not use the Python build infrastructure. Not now, though. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Open 7.1 items
* Bruce Momjian [EMAIL PROTECTED] [010129 14:03]: Fix ipcclean on Linux I believe Peter_E handled the above last week -- 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
Re: [HACKERS] Open 7.1 items
* Bruce Momjian [EMAIL PROTECTED] [010129 14:40]: * Bruce Momjian [EMAIL PROTECTED] [010129 14:03]: Fix ipcclean on Linux I believe Peter_E handled the above last week All I see is below, and the diff -c shows just the grep change. I thought that was all that was crabbed about?... --- revision 1.7 date: 2001/01/25 16:32:25; author: petere; state: Exp; lines: +2 -2 Avoid bogus failures due to 'ps x | grep postmaster' detecting 'grep postmaster' process. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- 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
[HACKERS] (forw) Re: CVS Commit message generator...
FYI... - Forwarded message from Jordan Hubbard [EMAIL PROTECTED] - From: Jordan Hubbard [EMAIL PROTECTED] Subject: Re: CVS Commit message generator... Date: Fri, 12 Jan 2001 19:50:33 -0800 Message-ID: [EMAIL PROTECTED] To: Larry Rosenman [EMAIL PROTECTED] Sure, it's all available from: ftp://ftp.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/CVSROOT Regards, - Jordan Jordan, Would it be possible to get a copy of whatever files are necessary to have a CVS server generate the commit messages like the FreeBSD project commits generate? I'm involved with the PostgreSQL project and our commits generate one message per directory, and would much prefer to see them move towards the FreeBSD style. Thanks for any help. -- 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 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
RE: [HACKERS] CVS updates on committers list...
I'm referring to the actual commit messages. It would be in the CVS server config -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: Friday, January 12, 2001 4:03 PM To: Larry Rosenman Cc: PostgreSQL Hackers List Subject: Re: [HACKERS] CVS updates on committers list... Well there is cvs2cl and there is a utility I use: pgsql/src/tools/pgcvslog Has anyone ever thought of asking the FreeBSD folks for their CVS COmmit message generator? They generate ONE message with more info in it for multi-directory commits than we do with ours. Thanks... -- 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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] psql -l bug
* Olivier PRENANT [EMAIL PROTECTED] [010110 12:47]: Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. I'm also on UW711, and do *NOT* see the bug: Password: List of databases Database | Owner | Encoding ---+--+--- ler | ler | SQL_ASCII postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (4 rows) Regards,, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- 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
Re: [HACKERS] psql -l bug
* Olivier PRENANT [EMAIL PROTECTED] [010110 15:03]: As I said previously.. I apologies, this was all my fault. Please discard... Oh my, When will we have an RC??? SOON. I'm running the BETA, LER On Wed, 10 Jan 2001, Larry Rosenman wrote: * Olivier PRENANT [EMAIL PROTECTED] [010110 12:47]: Hi, I just recompiled 7.1 beta from current CVS today. I pg_dump'ed my 7.02 db's and reloaded it on 7.1 with no probs apart that psql -l shows 2 template0 and template1... Template0 and template1 belong to user postgres and to an other who has no priviledges and no db!!! What makes me think it's a psql bug is that select * from pg_databases show 1 template0 and 1 template1. For what it's worth, it on unixware 711. BTW, when is the release due for? I'm VERY impatient. This is the best I've seen. I'm also on UW711, and do *NOT* see the bug: Password: List of databases Database | Owner | Encoding ---+--+--- ler | ler | SQL_ASCII postgres | postgres | SQL_ASCII template0 | postgres | SQL_ASCII template1 | postgres | SQL_ASCII (4 rows) Regards,, -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) -- 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
[HACKERS] Dec TRU64/PG 7.1
Has anyone tried 7.1Beta on Tru64? I've got an app that will be moving to this platform, and would like to not have any surprises (It's the first production app with PG in the dallas office, and would like to not make trouble). Thanks! 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
Re: [HACKERS] Current Sources/UW7.1.1
* Tom Lane [EMAIL PROTECTED] [010101 23:26]: Larry Rosenman [EMAIL PROTECTED] writes: * Tom Lane [EMAIL PROTECTED] [010101 23:16]: [snip] there are a couple of them that I *THINK* have more tuples on one side or the other of the Diff. I'll try and narrow them... (or shouldn't I bother? ) That would certainly be a bug, if so, so do look closer. An easy way to check for such a thing is to grep the regression.diffs file for differences in the "(n rows)" comments appended by psql. Ok, I get to be wrong. The only row difference is our friend random. Never Mind. Maybe regressplan should check for that? Larry 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
Re: [HACKERS] pg_dumpall (7.1beta1, current CVS)
* Tom Lane [EMAIL PROTECTED] [010101 13:16]: Larry Rosenman [EMAIL PROTECTED] writes: I noticed today that pg_dumpall from current CVS does *NOT* dump a password assiged to the postgres user. I consider this BAD, since if one has to restore from a pg_dumpall, one may forget to reset the password. I'm unconvinced. The pg_dumpall script is clearly intended to allow restoration into a new database installation with a different superuser; you will note that the script is careful not to assume that the old and new superuser names are the same (an assumption your proposed patch does make). In any case the new installation certainly already *has* a superuser. I'm not sure it's the job of the restore script to change his password for him. This does point up that there is some state that is not saved/restored by pg_dumpall --- the pg_hba.conf file and other config files that live in $PGDATA come to mind. Perhaps there should be a separate utility that saves/restores these. (pg_dump can't do it because there's no way to retrieve these files through a database connection.) How would you suggest doing this? A shell script that makes a SHAR or somesuch? Or what? Should it save the SuperUser password? I agree that this is a shortcoming. As to the SuperUser password thing, how do we remind the user that they had one set? Can we at least put out a comment in the pg_dumpall output that mentions it? 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
Re: [HACKERS] Current Sources/UW7.1.1
* Tom Lane [EMAIL PROTECTED] [010101 23:16]: [snip] there are a couple of them that I *THINK* have more tuples on one side or the other of the Diff. I'll try and narrow them... (or shouldn't I bother? ) -- 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
[HACKERS] pg_dumpall (7.1beta1, current CVS)
I noticed today that pg_dumpall from current CVS does *NOT* dump a password assiged to the postgres user. I consider this BAD, since if one has to restore from a pg_dumpall, one may forget to reset the password. 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
[HACKERS] Current Sources/UW7.1.1
The planregress.sh tests generate errors. Attached is a tar of the planregress directory... -- 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 planregress.tar.gz
Re: [HACKERS] CIDR output format
* Tom Lane [EMAIL PROTECTED] [001220 13:02]: Paul A Vixie [EMAIL PROTECTED] writes: cisco IOS just won't take 10/8 and insists on 10.0.0.0/8. you will never, ever go wrong if you try to use 10.0.0.0/8, since everything that understands CIDR understands that. 10/8 is a pleasant-appearing alternative format, but it is not universally accepted and i recommend against it. (i'm not sure if my original CIDR type implementation for pgsql output the shorthand or not; if it did, then i apologize to one and all.) Well, that's an earful. Faced with this authoritative opinion, I withdraw my previous objections to changing the output format for CIDR. It would seem that the appropriate behavior would be to make the default display format for CIDR be like "10.0.0.0/8". Now the text() conversion function already produces this same format. I'd be inclined to leave text() as-is and add a new conversion function with some other name (suggestions anyone?) that produces the shorthand form "10/8" as text, for those who prefer it. I would call it cidrshort(). I assume this also is true for INET? Thanks! LER Comments? 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
Re: [HACKERS] CIDR output format
* Tom Lane [EMAIL PROTECTED] [001221 09:49]:
Larry Rosenman [EMAIL PROTECTED] writes:
It would seem that the appropriate behavior would be to make the default
display format for CIDR be like "10.0.0.0/8". Now the text() conversion
function already produces this same format. I'd be inclined to leave
text() as-is and add a new conversion function with some other name
(suggestions anyone?) that produces the shorthand form "10/8" as text,
for those who prefer it.
I would call it cidrshort().
I was thinking something like abbrev(). There is no need to put the
type name in the function; that's what function overloading is for.
I assume this also is true for INET?
INET doesn't use abbreviation of the address part anyway. The only
display shortcut it has is to suppress "/32" when the netmask is 32.
I figured that text() could produce an un-abbreviated result for an
INET input (as it does now), and abbrev() could produce one with
/32 suppression. In short:
Value Default output text() abbrev()
'127.0.0.1/32'::inet 127.0.0.1 127.0.0.1/32127.0.0.1
'127.0.0.1/32'::cidr 127.0.0.1/32127.0.0.1/32127.0.0.1/32
'127/8'::cidr 127.0.0.0/8 127.0.0.0/8 127/8
This would be a little bit inconsistent, because the default output
format would match text() for CIDR values but abbrev() for INET values.
But that seems like the most useful behavior to me. Possibly others
will disagree ;-)
I'm fine with it. IIRC, you fixed it so we can cast from INET to CIDR
and back?
Thanks!
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
Re: [HACKERS] performance modality in 7.1 for large text attributes?
* Paul A Vixie [EMAIL PROTECTED] [001220 10:28]: Question is whether proper (standard/most-commonly-used) format for printing CIDR network address is 10/8 or 10.0.0.0/8 (i.e. should all octets be printed even if they are 0). After search of RFCs, there's nothing that specifies the standard, but 10.0.0.0/8 is used more often in examples than 10/8 form. Postgres uses 10/8 form, and I'm saying that 10.0.0.0/8 is more accepted by everyone else. (I.E. all software can deal with that, but not all software accepts 10/8). cisco IOS just won't take 10/8 and insists on 10.0.0.0/8. you will never, ever go wrong if you try to use 10.0.0.0/8, since everything that understands CIDR understands that. 10/8 is a pleasant-appearing alternative format, but it is not universally accepted and i recommend against it. (i'm not sure if my original CIDR type implementation for pgsql output the shorthand or not; if it did, then i apologize to one and all.) There was no way, prior to 7.1, to get all 4 octets printed using the original code. Thanks for clearing up the info. Larry Rosenman -- 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
Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE
* Alfred Perlstein [EMAIL PROTECTED] [001205 04:00]:
* Larry Rosenman [EMAIL PROTECTED] [001128 20:44] wrote:
* Tom Lane [EMAIL PROTECTED] [001128 22:31]:
Larry Rosenman [EMAIL PROTECTED] writes:
The last batch of commits break on FreeBSD 4.2-STABLE.
/usr/include/machine/lock.h:148: conflicting types for `s_lock'
../../../src/include/storage/s_lock.h:402: previous declaration of `s_lock'
That's odd. s_lock has been declared the same way right along in our
code; I didn't change it. Can you see what's changed to cause a
conflict where there was none before?
regards, tom lane
Other things that may be an issue:
1) BINUTILS 2.10.1
2) OPENSSL 0.9.6
both just MFC'd into FreeBSD recently, but I believe we built until
tonite.
I can make you an account on the box if you'd like
Grr, couldn't find the original message. I think you thought
you solved your problem with building on FreeBSD, however I
think you just forgot to compile with perl support enabled.
When I compiled with perl support it broke. This isn't a
postgresql bug, nor a FreeBSD bug although the fault lies
mostly with FreeBSD for polluting the C namespace a _lot_
when sys/mount.h is included.
Actually, perl support was included, and Tom's fix in the
cvs DID fix it, but fixing FreeBSD doesn't hurt. Here is
what I've been configuring with:
./configure --prefix=/home/ler/pg-test --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-openssl \
--with-includes="/usr/local/include/tcl8.3 /usr/local/include/tk8.3" \
--with-tcl \
--with-tclconfig=/usr/local/lib/tcl8.3 \
--with-tkconfig=/usr/local/lib/tk8.3
What happens is the the perl code brings in perl.h which brings
in sys/mount.h, sys/mount.h includes sys/lock.h because our
kernel structure "mount" has a VFS lock in it, VFS locks happen
to contain spinlocks (simplelocks) and one of our our functions
to manipulate the simplelocks is called s_lock(). This causes
a namespace conflict which causes the compile error.
Anyhow, to address the problem I've removed struct mount from
userland visibility in both FreeBSD 5.x (current) and FreeBSD 4.x
(stable).
Things should work now but let me know if you have any other
problems.
And thanks for pointing it out and offering to help track it
down.
here's the patch if you don't want to cvsup your machine all the
way.
Index: sys/sys/mount.h
===
RCS file: /home/ncvs/src/sys/sys/mount.h,v
retrieving revision 1.89
diff -u -r1.89 mount.h
--- sys/sys/mount.h 2000/01/19 06:07:34 1.89
+++ sys/sys/mount.h 2000/12/04 20:00:54
@@ -46,7 +46,9 @@
#endif /* !_KERNEL */
#include sys/queue.h
+#ifdef _KERNEL
#include sys/lock.h
+#endif
typedef struct fsid { int32_t val[2]; } fsid_t; /* file system id type */
@@ -99,6 +101,7 @@
longf_spare[2]; /* unused spare */
};
+#ifdef _KERNEL
/*
* Structure per mounted file system. Each mounted file system has an
* array of operations and an instance record. The file systems are
@@ -122,6 +125,7 @@
time_t mnt_time; /* last time written*/
u_int mnt_iosize_max; /* max IO request size */
};
+#endif /* _KERNEL */
/*
* User specifiable flags.
Index: usr.bin/fstat/cd9660.c
===
RCS file: /home/ncvs/src/usr.bin/fstat/cd9660.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 cd9660.c
--- usr.bin/fstat/cd9660.c2000/07/02 10:20:24 1.1.2.1
+++ usr.bin/fstat/cd9660.c2000/12/04 23:35:21
@@ -46,7 +46,9 @@
#include sys/stat.h
#include sys/time.h
#include sys/vnode.h
+#define _KERNEL
#include sys/mount.h
+#undef _KERNEL
#include isofs/cd9660/cd9660_node.h
Index: usr.bin/fstat/fstat.c
===
RCS file: /home/ncvs/src/usr.bin/fstat/fstat.c,v
retrieving revision 1.21.2.2
diff -u -r1.21.2.2 fstat.c
--- usr.bin/fstat/fstat.c 2000/07/02 10:28:38 1.21.2.2
+++ usr.bin/fstat/fstat.c 2000/12/04 20:01:08
@@ -66,8 +66,8 @@
#include sys/file.h
#include ufs/ufs/quota.h
#include ufs/ufs/inode.h
-#undef _KERNEL
#include sys/mount.h
+#undef _KERNEL
#include nfs/nfsproto.h
#include nfs/rpcv2.h
#include nfs/nfs.h
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
--
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
RE: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE
Actually, Alfred is a FreeBSD committer, and committed it to the FreeBSD source tree. It's for ALL at FreeBSD 4-STABLE as of today. LER -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 9:14 AM To: Alfred Perlstein Cc: Larry Rosenman; PostgreSQL Hackers List Subject: Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE Alfred Perlstein [EMAIL PROTECTED] writes: Anyhow, to address the problem I've removed struct mount from userland visibility in both FreeBSD 5.x (current) and FreeBSD 4.x (stable). That might fix things on your box, but we can hardly rely on it as an answer for everyone running FreeBSD :-(. Anyway, I've already worked around the problem by rearranging the PG headers so that plperl doesn't need to import s_lock.h ... regards, tom lane
Re: [HACKERS] compiling pg 7.0.3 on sco 5.0.5
* Tom Lane [EMAIL PROTECTED] [001204 09:27]: "Billy G. Allie" [EMAIL PROTECTED] writes: ... The DISABLE_COMPLEX_MACRO definition was originally put in to work around a macro size limitation of the UnixWare 2.1 C compiler (and later the SCO UDK (Universal Development Kit)). If the gnu C compiler is being used it should not be defined. Hm. Is anyone likely to still be using a version of that compiler that still has such limitations? I ask because we recently pulled "#define DISABLE_COMPLEX_MACRO" from port/sco.h, on the grounds that various people were seeing more harm than good from it. But I'm suddenly wondering whether those people might've been using gcc. I wonder if #ifndef __GNUC__ #define DISABLE_COMPLEX_MACRO #endif in port/sco.h would be the smart way to go. Based on my running both CURRENT UDK and GCC on my UnixWare 7 boxes with CURRENT sources, I think we may need to see if anyone complains. 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
Re: [HACKERS] [Fwd: Re: [CORE] Going Beta on Monday ...]
Macaddr manufacturer table update now in SQL table syslog configurability improvements. * Thomas Lockhart [EMAIL PROTECTED] [001204 13:42]: I browsed through the CVS logs and made this list of the important stuff. There's a ton of less important stuff... Shall we consider this the start of the list then? I think there may be a couple of things already mentioned in the release note stubs for 7.1 too. - Thomas Additional items: AT TIME ZONE clause for date/time types OVERLAPS operator support rewritten WAL --- fsync reliability without the performance hit TOAST --- 8K row limit is no longer significant outer joins (per SQL92 syntax, not Oracle's) subselects in FROM clause views and subselects now allow union/intersect/except, order by, limit views containing grouping, aggregates, DISTINCT work now bit-string types work now function manager overhaul: fixes portability problems, NULL-argument handling memory management overhaul: prevent memory leak accumulation during queries drop table and rename table are now rollback-able (transaction-safe) extensive overhaul of configure/build mechanism overhaul of parameter-setting mechanisms (postmaster flags, postmaster.opts, etc) more efficient large-object implementation pg_dump can dump large objects now pg_dump does the right thing with user-added objects in template1 support for binding postmaster's IP socket to a virtual host name support for placing postmaster's Unix socket file elsewhere than /tmp keep reference counts on syscache entries to avoid dropping still-used entries Protect against changes in LOCALE environment causing corrupted indexes better handling of unknown-type literals (default to string type more readily) inet/cidr datatypes cleaned up LIKE/ESCAPE implemented, also ILIKE (case-insensitive LIKE) aggregate-function support redesigned: only one transition function now, cleaner handling of NULLs STDDEV() and VARIANCE() aggregates added SUM() and AVG() on integer datatypes use NUMERIC accumulators Child tables are now scanned by default -- ie, if foo has children then SELECT FROM foo means SELECT FROM foo*. Ditto for UPDATE and DELETE. Use SELECT FROM ONLY foo if you don't want this behavior. vacuum analyze does the analyze part without holding exclusive lock -- 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
Re: [HACKERS] more fun with sco
* Arno A. Karner [EMAIL PROTECTED] [001130 10:09]:
thanks for the infor commented out define complex macro poof compiles :)
initdb works :)
createuser, createdb fail :( no entry in pg_hba.conf, have looked at it
looks like the standard default one on my linux box has entries for
local and for host 127.0.0.1
i would search the archives but when i tried to do that got page not
found on one of the groups, and not very meaningful, recent entries on
key word sco
i am assuming a lot of these problems are sco releated, because havent
had any problems running apache, php, postgres on linux, if i cant get
this running on sco my client gets my laptop running linux, untill i can
come up with apache + php + sql database on sco :(
will try more searchs but its deault config, and it is being parsed,
hacked it once mad typo gives me syntax error, removed hacks no syntax
error but access denied
sorry to be such a pest, for being on the mailing list for only a few
hours now, but the response and help ive got has been great, god i love
open source code
thanks in advance Arno
I assume 7.0.3 of PG...
Apply the following patch in src/backend/libpq:
*** pqcomm.c.oldThu May 25 20:26:19 2000
--- pqcomm.cSun Nov 12 12:03:25 2000
***
*** 354,359
--- 354,361
perror("postmaster: StreamConnection: accept");
return STATUS_ERROR;
}
+ if (port-raddr.sa.sa_family == 0)
+ port-raddr.sa.sa_family = AF_UNIX;
/* fill in the server (local) address */
addrlen = sizeof(port-laddr);
--
My opinions are my own and not that of my employer even if I am self
employed
--
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
Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE
* Tom Lane [EMAIL PROTECTED] [001128 23:03]: Larry Rosenman [EMAIL PROTECTED] writes: We've called that routine s_lock for a *long* time, so it seems like there must be some factor involved that I don't see just yet... Didn't your commit message say something about the TAS and NON-TAS paths being the same now? Yeah, but don't tell me you were running on a non-TAS platform... that stuff didn't work... Tom's commit from tonite fixed it. Regression running as I type... Thanks, Tom! 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
Re: [HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE
* Larry Rosenman [EMAIL PROTECTED] [001129 19:54]: * Tom Lane [EMAIL PROTECTED] [001128 23:03]: Larry Rosenman [EMAIL PROTECTED] writes: We've called that routine s_lock for a *long* time, so it seems like there must be some factor involved that I don't see just yet... Didn't your commit message say something about the TAS and NON-TAS paths being the same now? Yeah, but don't tell me you were running on a non-TAS platform... that stuff didn't work... Tom's commit from tonite fixed it. Regression running as I type... and passed. :-) Thanks, Tom! 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 -- 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
Re: [HACKERS] LOCK Fixes/Break on FreeBSD 4.2-STABLE
BTW, it compiles fine on UnixWare 7.1.1 * Larry Rosenman [EMAIL PROTECTED] [001128 19:36]: The last batch of commits break on FreeBSD 4.2-STABLE. $ uname -a FreeBSD lerbsd.lerctr.org 4.2-STABLE FreeBSD 4.2-STABLE #90: Tue Nov 28 04:07:50 CST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/LERBSD i386 $ Configure: ./configure --prefix=/home/ler/pg-test --enable-syslog \ --with-CXX --with-perl --enable-multibyte --enable-cassert \ --with-openssl \ --with-includes="/usr/local/include/tcl8.3 /usr/local/include/tk8.3" \ --with-tcl \ --with-tclconfig=/usr/local/lib/tcl8.3 \ --with-tkconfig=/usr/local/lib/tk8.3 Last 50 lines of make output: ranlib libplpgsql.a /usr/libexec/elf/ld -x -shared -soname libplpgsql.so.1 -o libplpgsql.so.1 pl_parse.o pl_handler.o pl_comp.o pl_exec.o pl_funcs.o -R/home/ler/pg-test/lib rm -f libplpgsql.so ln -s libplpgsql.so.1 libplpgsql.so gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/plpgsql/src' gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/plpgsql' gmake[3]: Entering directory `/home/ler/pg-dev/pgsql/src/pl/tcl' /bin/sh mkMakefile.tcldefs.sh '/usr/local/lib/tcl8.3/tclConfig.sh' 'Makefile.tcldefs' gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/tcl' gmake[3]: Entering directory `/home/ler/pg-dev/pgsql/src/pl/tcl' cc -O -fPIC -I/usr/local/include/tcl8.3 -I/usr/local/include/tk8.3 -I../../../src/include -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_TM_GMTOFF=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -DNEED_MATHERR=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_FILIO_H=1 -c -o pltcl.o pltcl.c ld -Bshareable -x -o pltcl.so pltcl.o -L/usr/local/lib -ltcl83 rm pltcl.o gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/tcl' gmake[3]: Entering directory `/home/ler/pg-dev/pgsql/src/pl/plperl' plperl_installdir='/home/ler/pg-test/lib' \ EXTRA_INCLUDES='-I/usr/local/include/tcl8.3 -I/usr/local/include/tk8.3 -I../../../src/include' \ perl Makefile.PL Writing Makefile for plperl gmake -f Makefile all gmake[4]: Entering directory `/home/ler/pg-dev/pgsql/src/pl/plperl' mkdir blib mkdir blib/lib mkdir blib/arch mkdir blib/arch/auto mkdir blib/arch/auto/plperl mkdir blib/lib/auto mkdir blib/lib/auto/plperl cc -c -I/usr/local/include/tcl8.3 -I/usr/local/include/tk8.3 -I../../../src/include -DVERSION=\"0.10\" -DXS_VERSION=\"0.10\" -DPIC -fpic -I/usr/libdata/perl/5.00503/mach/CORE plperl.c In file included from plperl.c:80: /usr/libdata/perl/5.00503/mach/CORE/perl.h:1483: warning: `DEBUG' redefined ../../../src/include/utils/elog.h:22: warning: this is the location of the previous definition In file included from /usr/include/sys/lock.h:45, from /usr/include/sys/mount.h:49, from /usr/libdata/perl/5.00503/mach/CORE/perl.h:376, from plperl.c:80: /usr/include/machine/lock.h:148: conflicting types for `s_lock' ../../../src/include/storage/s_lock.h:402: previous declaration of `s_lock' gmake[4]: *** [plperl.o] Error 1 gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/plperl' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl/plperl' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/pl' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 $ ^D Script done on Tue Nov 28 19:32:31 2000 BTW: this is the same configure I was using after Peter_E fixed the TCL / --with-includes 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 -- 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
[HACKERS] Re: LOCK Fixes/Break on FreeBSD 4.2-STABLE
* Tom Lane [EMAIL PROTECTED] [001128 22:31]:
Larry Rosenman [EMAIL PROTECTED] writes:
The last batch of commits break on FreeBSD 4.2-STABLE.
/usr/include/machine/lock.h:148: conflicting types for `s_lock'
../../../src/include/storage/s_lock.h:402: previous declaration of `s_lock'
That's odd. s_lock has been declared the same way right along in our
code; I didn't change it. Can you see what's changed to cause a
conflict where there was none before?
This maybe Matt Dillon's recent commit to FBSD then. Either way, it's
a problem on -STABLE 4.2 of FreeBSD.
Here is the "Current" /usr/include/machine/lock.h:
/*
* Copyright (c) 1997, by Steve Passe
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. The name of the developer may NOT be used to endorse or promote products
*derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD: src/sys/i386/include/lock.h,v 1.11.2.2 2000/09/30 02:49:34 ps Exp $
*/
#ifndef _MACHINE_LOCK_H_
#define _MACHINE_LOCK_H_
#ifdef LOCORE
#ifdef SMP
#define MPLOCKEDlock ;
/*
* Some handy macros to allow logical organization.
*/
#define MP_LOCK call_get_mplock
#define MP_TRYLOCK \
pushl $_mp_lock ; /* GIANT_LOCK */\
call_MPtrylock ;/* try to get lock */ \
add $4, %esp
#define MP_RELLOCK \
movl$_mp_lock,%edx ;/* GIANT_LOCK */\
call_MPrellock_edx
/*
* Protects the IO APIC and apic_imen as a critical region.
*/
#define IMASK_LOCK \
pushl $_imen_lock ; /* address of lock */ \
call_s_lock ; /* MP-safe */ \
addl$4, %esp
#define IMASK_UNLOCK\
movl$0, _imen_lock
#else /* SMP */
#define MPLOCKED/* NOP */
#define MP_LOCK /* NOP */
#endif /* SMP */
#else /* LOCORE */
#ifdef SMP
#include machine/smptests.h /** xxx_LOCK */
/*
* Locks regions protected in UP kernel via cli/sti.
*/
#ifdef USE_MPINTRLOCK
#define MPINTR_LOCK() s_lock(mpintr_lock)
#define MPINTR_UNLOCK() s_unlock(mpintr_lock)
#else
#define MPINTR_LOCK()
#define MPINTR_UNLOCK()
#endif /* USE_MPINTRLOCK */
/*
* sio/cy lock.
* XXX should rc (RISCom/8) use this?
*/
#ifdef USE_COMLOCK
#define COM_LOCK() s_lock(com_lock)
#define COM_UNLOCK()s_unlock(com_lock)
#define COM_DISABLE_INTR() \
{ __asm __volatile("cli" : : : "memory"); COM_LOCK(); }
#define COM_ENABLE_INTR() \
{ COM_UNLOCK(); __asm __volatile("sti"); }
#else
#define COM_LOCK()
#define COM_UNLOCK()
#define COM_DISABLE_INTR() disable_intr()
#define COM_ENABLE_INTR() enable_intr()
#endif /* USE_COMLOCK */
/*
* Clock hardware/struct lock.
* XXX pcaudio and friends still need this lock installed.
*/
#ifdef USE_CLOCKLOCK
#define CLOCK_LOCK()s_lock(clock_lock)
#define CLOCK_UNLOCK() s_unlock(clock_lock)
#define CLOCK_DISABLE_INTR() \
{ __asm __volatile("cli" : : : "memory"); CLOCK_LOCK(); }
#define CLOCK_ENABLE_INTR() \
{ CLOCK_UNLOCK(); __asm __volatile("sti"); }
#else
#define CLOCK_LOCK()
#define CLOCK_UNLOCK()
#define CLOCK_DISABLE_INTR()disable_intr()
#define CLOCK_ENABLE_INTR() enable_intr()
#endif /* USE_CLOCKLOCK */
#else /* SMP */
#define MPINTR_LOCK()
#define MPINTR_UNLOCK()
#define COM_LOCK()
#define COM_UNLOCK()
#define CLOCK_LOCK()
#define CLOCK_UNLOCK()
#endif /* SMP */
/*
* Simple spin lock.
* It is an error to hold one of these locks while a process
