Re: [HACKERS] \xDD patch for 7.5devel
--On Thursday, November 06, 2003 07:43:07 +1100 Jason Godden [EMAIL PROTECTED] wrote: On Thu, 6 Nov 2003 06:25 am, Markus Bertheau wrote: ? ???, 05.11.2003, ? 16:25, Tom Lane ?: +#define HEXVALUE(c) (((c)='a') ? ((c)-87) : (((c)='A') ? ((c)-55) : ((c)-'0'))) This seems excessively dependent on the assumption that the character set is ASCII. Why have you hard-coded numeric equivalents into this macro? What not ASCII compatible character sets are out there in use still today? EBCDIC as far as I know is still the default on IBM Mainframes (been 5+ years but...). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] OpenServer 5.0.7: setsockopt(TCP_NODELAY)?
I asked my friends at SCO (who are productizing PG) to test 7.4RC1 on OpenServer 5.0.7, and received this back: A make check fails at createdb with errors in the postmaster logfile: LOG: setsockopt(TCP_NODELAY) failed: Protocol not available Plus he needed to add: if test $GCC != yes ; then CC=$CC -b elf fi to src/template/sco for 5.0.7. I downloaded 7.4 RC1 and successfully compiled it on an OpenServer 5.0.7 system. I am attaching the only change i had to make. This is the file src/template/sco. The GCC compiler on OSR5 no longer accepts the -b elf argument. Anyone of the guru's have ideas? 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] OpenServer 5.0.7: setsockopt(TCP_NODELAY)?
--On Thursday, November 06, 2003 20:19:05 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: A make check fails at createdb with errors in the postmaster logfile: LOG: setsockopt(TCP_NODELAY) failed: Protocol not available [snip] Better ask them what their problem is with that ... Done, I don't expect an answer till tomorrow. Thanks for the quick diagnosis. LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] OSR5: Passes without the setsockopt() calls...
From my SCO contacts re: the failure on OSR5:
I haven't had time and won't have time to fully diagnose this until
after i get back from vacation. In the mean time, i am attaching a
patch which gets OpenServer 5.0.7 to pass 92 of 93 tests with one
test ignored. Basically, this patch just says if you're on OpenServer
then don't do the setsockopt calls. Not very satisfactory as setsockopt
should work on OSR5.
I know this isn't an acceptable patch, and I'm not sure when my contact
is back from Vacation.
Do we want to hold the release?
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
--- ./src/backend/libpq/auth.c.00 2003-09-26 15:27:31.0 +
+++ ./src/backend/libpq/auth.c 2003-11-08 22:54:32.0 +
@@ -480,6 +480,7 @@
* only if it is defined and SO_PEERCRED isn't.
*/
#if defined(HAVE_STRUCT_FCRED) || defined(HAVE_STRUCT_SOCKCRED)
+#ifndef _SCO_DS
/*
* Receive credentials on next message receipt, BSD/OS,
@@ -495,6 +496,7 @@
errmsg(could not enable credential
reception: %m)));
}
#endif
+#endif
if (port-raddr.addr.ss_family == AF_UNIX)
sendAuthRequest(port, AUTH_REQ_SCM_CREDS);
#endif
--- ./src/backend/libpq/pqcomm.c.00 2003-09-25 06:57:59.0 +
+++ ./src/backend/libpq/pqcomm.c2003-11-08 22:55:19.0 +
@@ -312,6 +312,7 @@
continue;
}
+#ifndef _SCO_DS
if (!IS_AF_UNIX(addr-ai_family))
{
if ((setsockopt(fd, SOL_SOCKET, SO_REUSEADDR,
@@ -324,8 +325,10 @@
continue;
}
}
+#endif
#ifdef IPV6_V6ONLY
+#ifndef _SCO_DS
if (addr-ai_family == AF_INET6)
{
if (setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY,
@@ -339,6 +342,7 @@
}
}
#endif
+#endif
/*
* Note: This might fail on some OS's, like Linux older than
@@ -548,6 +552,7 @@
}
/* select NODELAY and KEEPALIVE options if it's a TCP connection */
+#ifndef _SCO_DS
if (!IS_AF_UNIX(port-laddr.addr.ss_family))
{
int on;
@@ -569,6 +574,7 @@
return STATUS_ERROR;
}
}
+#endif
return STATUS_OK;
}
--- ./src/interfaces/libpq/fe-connect.c.00 2003-10-18 05:02:06.0 +
+++ ./src/interfaces/libpq/fe-connect.c 2003-11-08 22:55:41.0 +
@@ -797,6 +797,7 @@
static int
connectNoDelay(PGconn *conn)
{
+#ifndef _SCO_DS
#ifdef TCP_NODELAY
int on = 1;
@@ -812,6 +813,7 @@
return 0;
}
#endif
+#endif
return 1;
}
--- ./src/template/sco.00 2003-10-09 03:20:34.0 +
+++ ./src/template/sco 2003-11-06 23:07:14.0 +
@@ -1,2 +1,3 @@
-CC=$CC -b elf
-
+if test $GCC != yes ; then
+CC=$CC -b elf
+fi
pgp0.pgp
Description: PGP signature
Re: [HACKERS] OSR5: Passes without the setsockopt() calls...
Can I get a comment from someone on this please... LER --On Saturday, November 08, 2003 18:03:45 -0600 Larry Rosenman [EMAIL PROTECTED] wrote: From my SCO contacts re: the failure on OSR5: I haven't had time and won't have time to fully diagnose this until after i get back from vacation. In the mean time, i am attaching a patch which gets OpenServer 5.0.7 to pass 92 of 93 tests with one test ignored. Basically, this patch just says if you're on OpenServer then don't do the setsockopt calls. Not very satisfactory as setsockopt should work on OSR5. I know this isn't an acceptable patch, and I'm not sure when my contact is back from Vacation. Do we want to hold the release? 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Experimental patch for inter-page delay in VACUUM
--On Monday, November 10, 2003 11:40:45 -0500 Neil Conway [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: Now, the disadvantages of large kernel cache, small PostgreSQL buffer cache is that data has to be transfered to/from the kernel buffers, and second, we can't control the kernel's cache replacement strategy, and will probably not be able to in the near future, while we do control our own buffer cache replacement strategy. The intent of the posix_fadvise() work is to at least provide a few hints about our I/O patterns to the kernel's buffer cache. Although only Linux supports it (right now), that should hopefully improve the status quo for a fairly significant portion of our user base. I'd be curious to see a comparison of the cost of transferring data from the kernel's buffers to the PG bufmgr. You might also look at Veritas' advisory stuff. If you want exact doc pointers, I can provide them, but they are in the Filesystem section of http://www.lerctr.org:8458/ LER -Neil ---(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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Experimental patch for inter-page delay in VACUUM
--On Monday, November 10, 2003 13:40:24 -0500 Neil Conway [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: You might also look at Veritas' advisory stuff. Thanks for the suggestion -- it looks like we can make use of this. For the curious, the cache advisory API is documented here: http://www.lerctr.org:8458/en/man/html.7/vxfsio.7.html http://www.lerctr.org:8458/en/ODM_FSadmin/fssag-9.html#MARKER-9-1 Note that unlike for posix_fadvise(), the docs for this functionality explicitly state: Some advisories are currently maintained on a per-file, not a per-file-descriptor, basis. This means that only one set of advisories can be in effect for all accesses to the file. If two conflicting applications set different advisories, both use the last advisories that were set. BTW, if ANY developer wants to play with this, I can make an account for them. I have ODM installed on lerami.lerctr.org (www.lerctr.org is a CNAME). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Any more must fix issues for 7.4?
--On Thursday, November 13, 2003 12:43:37 -0500 Tom Lane [EMAIL PROTECTED] wrote: Barring surprises, we will institute a code freeze in the 7.4 branch tonight with an eye to wrapping the release Sunday. Is anyone aware of critical loose ends that still need to be dealt with? The only thing on my own radar screen is a couple of reports of the stats collector failing to start on Solaris; but it is not yet clear whether that's our bug or a misconfiguration problem on those boxes, and I don't want to hold up the release while we find out. The only thing I'm aware of is the setsockopt() issue on OpenServer. LER regards, tom lane ---(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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Any more must fix issues for 7.4?
--On Thursday, November 13, 2003 13:18:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: The only thing I'm aware of is the setsockopt() issue on OpenServer. We have no proposed patch for that, either, so it will also have to wait for 7.4.1. modulo the unacceptable one. I'm aware of that. We may want to note it somewhere... regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] REL7_4_STABLE: configure breakage?
I just updated to the current REL7_4_STABLE cvs, and get a problem at line 18048 where cat isn't on the path writing the config.status file. If I add /usr/bin/ to the cat invocation, it works. What's broke? (I updated using: cvs update -rREL7_4_STABLE -P -d ) LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] interesting SIGNAL 10 (BUSERR) on CVS
running 7.4RC2+ (from last week). I got the following: $ debug -ic -c core* /usr/local/pgsql/bin/postgres Warning: No debugging information in /usr/local/pgsql/bin/postgres Core image of postgres (process p1) created CORE FILE [_bt_getroot] SIGNALED 10 (bus code[BUS_OBJERR] address[0xbb12c550]) in p1 0x808f057 (_bt_getroot+135:)movzwl 16(%edi),%edx debug trace ^ Error: Unrecognized keyword at trace debug stack Stack Trace for p1, Program postgres *[0] _bt_getroot(0x83520dc, 0x1)[0x808f057] [1] _bt_search(presumed: 0x83520dc, 0x1, 0x838560c)[0x809350d] [2] _bt_first(presumed: 0x83853d8, 0x1, 0x8385400) [0x809443e] [3] btgettuple() [0x8091fa6] debug It's a one shot, and I have a core, but, I don't have the debug symbols as UnixWare's cc doesn't allow -g and -O. Do we care? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] interesting SIGNAL 10 (BUSERR) on CVS
--On Sunday, November 16, 2003 12:59:43 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: I got the following: $ debug -ic -c core* /usr/local/pgsql/bin/postgres Warning: No debugging information in /usr/local/pgsql/bin/postgres Core image of postgres (process p1) created CORE FILE [_bt_getroot] SIGNALED 10 (bus code[BUS_OBJERR] address[0xbb12c550]) in p1 0x808f057 (_bt_getroot+135:)movzwl 16(%edi),%edx Is it repeatable? It's hard to see how _bt_getroot() could core except maybe in the presence of serious data corruption in the index ... it happened once, and postgres did a restart. The cronjob that triggered it (WebCalendar's sendreminders script), has run since. So, I don't know. I just thought it was weird. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] interesting SIGNAL 10 (BUSERR) on CVS
--On Sunday, November 16, 2003 13:15:27 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: Is it repeatable? It's hard to see how _bt_getroot() could core except maybe in the presence of serious data corruption in the index ... it happened once, and postgres did a restart. The cronjob that triggered it (WebCalendar's sendreminders script), has run since. So, I don't know. Hmm. It might be worth running memtest86 to look for flaky RAM. I doubt it's worth the effort to try to extract any info from a core file with no symbols :-( Okie. I just figured I'd give a heads up that it happened. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] help!
I screwed up, and dropped a column when I shouldn't have. I have *not* vacuumed this DB yet. Is there any catalog mucking I can do to bring it back? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] help!
--On Monday, November 17, 2003 19:36:08 -0600 Larry Rosenman [EMAIL PROTECTED] wrote: I screwed up, and dropped a column when I shouldn't have. I have *not* vacuumed this DB yet. Is there any catalog mucking I can do to bring it back? Actually, I got lucky. pg_catalog.pg_attribute is what I needed to muck with, and I got the column I needed back, and then translated. 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] help!
--On Tuesday, November 18, 2003 09:59:32 +0800 Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Wait for confirmation from at least one other developer perhaps, buy you can try this: 1. Set attisdropped to false for the attribute 2. Set the atttypid back to whatever the oid of the type of that column is/was (Compare to an undropped similar column) 3. Use ALTER TABLE/SET NOT NULL on the column if it was originally NOT NULL 4. Set attstattarget to -1 to re-enable stat gathering 5. Rename the column (attname field) back to whatever it was. 6. Re set the default on the column 7. Done. (I think) By the way, vacuuming doesn't necessarily have much to do with it - updating rows does though. I'm not 100% sure what will happen exactly when you follow the steps above (reversing what's in RemoveAttributeById). I did the following, and was able to do what I needed to do: update pg_catalog.pg_attribute set attname='instance1',attisdropped='f',attypid=1048 where attrelid=2356153 and attname='pg.dropped.6'; and then re-do the stuff that my rt needed, and then re-drop the column. (basically the RT docs blew one character in a field name, and I wasn't paying attention :-) ) LER Chris Larry Rosenman wrote: I screwed up, and dropped a column when I shouldn't have. I have *not* vacuumed this DB yet. Is there any catalog mucking I can do to bring it back? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Release cycle length
--On Tuesday, November 18, 2003 04:43:12 +0100 Peter Eisentraut [EMAIL PROTECTED] wrote: Neil Conway writes: That said, I'm not really sure how we can make better use of the beta period. One obvious improvement would be making the beta announcements more visible: the obscurity of the beta process on www.postgresql.org for 7.4 was pretty ridiculous. Does anyone else have a suggestion on what we can do to produce a more reliable .0 release in less time? Here are a couple of ideas: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. The only reason we had last minute stuff for UnixWare this time was the timing of PG's release and the UP3 release from SCO. I try to test stuff fairly frequently, and this time I didn't know when, exactly, SCO would make the release of the updated compiler. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] 4 Clause license?
--On Thursday, November 20, 2003 16:00:44 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: On Thu, 20 Nov 2003, Joshua D. Drake wrote: Based on the below wouldn't they also have to go after Microsoft? Depends ... does MicroSoft use BSD TCP/IP, or did they write their own? I know that Linux is not using BSD TCP/IP (or, at least, they didn't in their first 3 incarnations of the stack) ... M$ also bought a LARGE license from SCO... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] 7.4final regression failure on uw713
On Tue, 25 Nov 2003, Tom Lane wrote: [EMAIL PROTECTED] writes: Don't know if it's bad, but make check reports a regression failure on join. I believe we'd determined that this is an acceptable platform-specific behavior. Yep. Due to the new qsort() in 713UP3. LER regards, tom lane ---(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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.4.1 ... slight change of scheduale ...
--On Friday, December 05, 2003 12:47:40 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: To accomodate ppls travel scheduales, we are going to move the 7.4.1 release up to Monday, *unless* there is a report before then about something that needs to be fixed first ... we know of nothing outstanding right now ... Possibly the C error in pg_autovacuum re: time calcs? (see the -performance list from yesterday, conversation between Vivek Khera(sp?) and myself). This means it will be tag'd/bundled on Sunday ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] [COMMITTERS] pgsql-server/ oc/src/sgml/Tag: oc/src/sgml/REL ...
Do we need to reinitdb to pick this up, or just run this file? Curiousity. --On Sunday, December 07, 2003 06:18:50 -0400 Peter Eisentraut - PostgreSQL [EMAIL PROTECTED] wrote: CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/12/07 06:18:50 Modified files: doc/src/sgml : Tag: REL7_4_STABLE release.sgml src/backend/catalog: Tag: REL7_4_STABLE information_schema.sql Log message: Fix typmod interpretation for bit types. (It was erroneously assumed thatfor bit(x), the typmod stores x+4, like for the character types.) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] [COMMITTERS] pgsql-server/ oc/src/sgml/Tag:
--On Tuesday, December 09, 2003 23:13:15 +0100 Peter Eisentraut [EMAIL PROTECTED] wrote: Larry Rosenman wrote: Do we need to reinitdb to pick this up, or just run this file? It's actually described in the release notes: Thanks! Thats what I get for not reading the SGML stuff. quickie script did the trick. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] TODO list
--On Thursday, December 18, 2003 08:07:03 +1100 Gavin Sherry [EMAIL PROTECTED] wrote: On Wed, 17 Dec 2003, Bruce Momjian wrote: Marko Zmak wrote: I've been usin psql for quite a long time and I found it to be very comfortable. Since some web providers in my country refuse to put psql while some thing are still in psql TODO list, I'm interested in following... I'd like to know when are you planning to deal with this TODO item: Allow limits on per-db/user connections I would appreciate if it was as soon as possible. Thanks. I know of no one working on this feature. But I'm sure no one would have a problem with Marko attempting it :-). I also know that Olivier PRENANT was looking for something similar. And the same admonition goes. I.E., you have an itch, we'd love to see you scratch it. LER Gavin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Preventing stack-overflow crashes (improving on
--On Wednesday, December 31, 2003 11:20:49 -0500 Tom Lane [EMAIL PROTECTED] wrote: Gaetano Mendola [EMAIL PROTECTED] writes: Is ABS enough on a 64-bit architecture ? That was pseudocode, I wasn't actually planning to rely on a function. Something more like long diff; diff = stack_base_ptr - stack_top_loc; if (diff 0) diff = -diff; if (diff max) elog ... One archetecture that MIGHT be an issue (It's been 5+ years) is IBM 390 class under Z/OS. I'm not sure how they do stacks LER regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] what does it mean
--On Monday, January 26, 2004 12:11:19 -0500 Tom Lane [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: I've upgraded my production system to 741 yesterday, and just discovered this log message: statistic buffer is full. If you see this a lot, it might be worth increasing PGSTAT_RECVBUFFERSZ. How much is a lot? it occured ~30 times since 23pm (it's 17:48 pm now) Hm. I wonder whether something is interfering with the stats collection code on your system? I can't recall anyone else reporting seeing this log message, so I'm not convinced that PGSTAT_RECVBUFFERSZ is too small. What platform are you using, again? UnixWare 7.1.3 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Write cache
IDE or SCSI? Why do you think the WC is screwing you? Which driver(s)? LER --On Tuesday, January 27, 2004 22:34:46 +0100 [EMAIL PROTECTED] wrote: Because I've lost a lot of data using postgresql (and I know for sure this should'nt happen) I've gone a bit further reading documentations on my disks and... I have FUJITSU MAP3367NC 36G 1 rpm disks, those disk have a write cache of 8Mb, if someone could tell me hox to turn it off... Could'nt find it in the docs and this could very well explain why a busy database crashes every time Thanks for your help -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Write cache
--On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:38:30 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache IDE or SCSI? SCSI Why do you think the WC is screwing you? Because after a sys crash, the most used filesystems (databases) are screwed what VxFS mount options are you using? Which driver(s)? Guess... ADPU320 Hrm. LER --On Tuesday, January 27, 2004 22:34:46 +0100 [EMAIL PROTECTED] wrote: Because I've lost a lot of data using postgresql (and I know for sure this should'nt happen) I've gone a bit further reading documentations on my disks and... I have FUJITSU MAP3367NC 36G 1 rpm disks, those disk have a write cache of 8Mb, if someone could tell me hox to turn it off... Could'nt find it in the docs and this could very well explain why a busy database crashes every time Thanks for your help -- Olivier PRENANTTel: +33-5-61-50-97-00 (Work) 6, Chemin 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) 6, Chemin 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Write cache
--On Tuesday, January 27, 2004 22:48:42 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:45:20 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache --On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:38:30 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache IDE or SCSI? SCSI Why do you think the WC is screwing you? Because after a sys crash, the most used filesystems (databases) are screwed what VxFS mount options are you using? Nothing special... And any option I could use would'nt change a thing: the cache is on the disk itself... I did'nt look physicaly yet but according to the docs there's no way to disable it lik I always did on IBM... I was forced to buy those disk (more expensive, not better) define not special? ISTM that the driver should force it out to the disk, unless the disk is lying to the driver, or the driver is buggy. Which driver(s)? Guess... ADPU320 Hrm. LER --On Tuesday, January 27, 2004 22:34:46 +0100 [EMAIL PROTECTED] wrote: Because I've lost a lot of data using postgresql (and I know for sure this should'nt happen) I've gone a bit further reading documentations on my disks and... I have FUJITSU MAP3367NC 36G 1 rpm disks, those disk have a write cache of 8Mb, if someone could tell me hox to turn it off... Could'nt find it in the docs and this could very well explain why a busy database crashes every time Thanks for your help -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin 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 PRENANTTel: +33-5-61-50-97-00 (Work) 6, Chemin 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) 6, Chemin 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Write cache
--On Tuesday, January 27, 2004 23:01:45 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:55:49 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache --On Tuesday, January 27, 2004 22:48:42 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:45:20 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache --On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:38:30 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache IDE or SCSI? SCSI Why do you think the WC is screwing you? Because after a sys crash, the most used filesystems (databases) are screwed what VxFS mount options are you using? Nothing special... And any option I could use would'nt change a thing: the cache is on the disk itself... I did'nt look physicaly yet but according to the docs there's no way to disable it lik I always did on IBM... I was forced to buy those disk (more expensive, not better) define not special? ISTM that the driver should force it out to the disk, unless the disk is lying to the driver, or the driver is buggy. That's exactly what I think: the DISK has a write cache so it's lying to the controler saying data is written when it's only in the disk cache. That also would explain the fantastic write performance I have compared to read... SO, I consider these disks buggy or not acceptable for use. LER Which driver(s)? Guess... ADPU320 Hrm. LER --On Tuesday, January 27, 2004 22:34:46 +0100 [EMAIL PROTECTED] wrote: Because I've lost a lot of data using postgresql (and I know for sure this should'nt happen) I've gone a bit further reading documentations on my disks and... I have FUJITSU MAP3367NC 36G 1 rpm disks, those disk have a write cache of 8Mb, if someone could tell me hox to turn it off... Could'nt find it in the docs and this could very well explain why a busy database crashes every time Thanks for your help -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin 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) 6, Chemin 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 PRENANTTel: +33-5-61-50-97-00 (Work) 6, Chemin 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) 6, Chemin 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Write cache
--On Tuesday, January 27, 2004 23:03:56 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 16:02:40 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache --On Tuesday, January 27, 2004 23:01:45 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:55:49 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache --On Tuesday, January 27, 2004 22:48:42 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:45:20 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache --On Tuesday, January 27, 2004 22:43:34 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: Date: Tue, 27 Jan 2004 15:38:30 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: Write cache IDE or SCSI? SCSI Why do you think the WC is screwing you? Because after a sys crash, the most used filesystems (databases) are screwed what VxFS mount options are you using? Nothing special... And any option I could use would'nt change a thing: the cache is on the disk itself... I did'nt look physicaly yet but according to the docs there's no way to disable it lik I always did on IBM... I was forced to buy those disk (more expensive, not better) define not special? ISTM that the driver should force it out to the disk, unless the disk is lying to the driver, or the driver is buggy. That's exactly what I think: the DISK has a write cache so it's lying to the controler saying data is written when it's only in the disk cache. That also would explain the fantastic write performance I have compared to read... SO, I consider these disks buggy or not acceptable for use. So do I... I have 6 disks... 250$ each... What kind of warranty? How Old? LER Which driver(s)? Guess... ADPU320 Hrm. LER --On Tuesday, January 27, 2004 22:34:46 +0100 [EMAIL PROTECTED] wrote: Because I've lost a lot of data using postgresql (and I know for sure this should'nt happen) I've gone a bit further reading documentations on my disks and... I have FUJITSU MAP3367NC 36G 1 rpm disks, those disk have a write cache of 8Mb, if someone could tell me hox to turn it off... Could'nt find it in the docs and this could very well explain why a busy database crashes every time Thanks for your help -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin 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) 6, Chemin 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) 6, Chemin 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 PRENANTTel: +33-5-61-50-97-00 (Work) 6, Chemin 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) 6, Chemin 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
Re: [HACKERS] Write cache
--On Tuesday, January 27, 2004 23:15:09 +0100 [EMAIL PROTECTED] wrote: On Tue, 27 Jan 2004, Larry Rosenman wrote: ISTM that the driver should force it out to the disk, unless the disk is lying to the driver, or the driver is buggy. That's exactly what I think: the DISK has a write cache so it's lying to the controler saying data is written when it's only in the disk cache. That also would explain the fantastic write performance I have compared to read... SO, I consider these disks buggy or not acceptable for use. So do I... I have 6 disks... 250$ each... What kind of warranty? 3 years 24 hours on site (the computer altogather) How Old? 3 months I'd tell them to get you disks that don't lie. and be FIRM about 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] session IDs
--On Tuesday, February 03, 2004 11:12:03 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: Peter Eisentraut wrote: Andrew Dunstan wrote: I am less sure of the utility of such an ID, though. After all, if you see a disconnect log message for a given PID you must know that any reuse of that PID indicates a new session, or even if you just see a connection message you know it must be a new session. OTOH, having a unique SessionID might simplify the logic required of log analysis tools. The PID *is* a unique session ID. Why is it not sufficient? It's unique for the duration of the session, but it won't be for logs covering a sufficient period of time, because PIDs are reused, in some cases not even by cycling but being allocated randomly. As I said elsewhere, I can live with that, but others wanted something that was more unique (if such a term has meaning ;-) How about pid+unix time of start of backend? LER cheers andrew (You are unique. Just like everybody else.) ---(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 pgp0.pgp Description: PGP signature
Re: [HACKERS] Too-many-files errors on OS X
--On Sunday, February 22, 2004 23:00:31 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Kevin Brown [EMAIL PROTECTED] writes:
I wasn't able to test on HP-UX
I get the same result on HPUX, after whacking the test program around
a bit: no change in the number of files we can open. Confirmations on
other platforms please, anyone?
For anyone else who has problems getting it to compile, try copying
the relevant version of pg_dlopen from src/backend/port/dynloader/.
I attach the code I actually ran on HPUX.
regards, tom lane
On FreeBSD 5:
$ ./eatfds3 /usr/local/lib/libpq.so /usr/lib/libm.so
dup() failed: Too many open files
Was able to use 7146 file descriptors
dup() failed: Too many open files
Was able to use 7146 file descriptors after opening 2 shared libs
$
On UnixWare 7.1.4:
$ ./eatfds3 /usr/lib/libpq.so.3 /usr/lib/libm.so.1
dup() failed: Too many open files
Was able to use 2045 file descriptors
dup() failed: Too many open files
Was able to use 2045 file descriptors after opening 2 shared libs
$
I had to hack on the code some more for FreeBSD:
(the realloc call needed the multiplication). I ran this same code
on UnixWare.
$ cat eatfds3.c
#include stdio.h
#include string.h
#include errno.h
#include stdlib.h
#include unistd.h
#include dlfcn.h
// these seem to be needed on HPUX:
//#include a.out.h
//#include dl.h
int *fd;
int size = 3072;
void *
pg_dlopen(char *filename)
{
/*
* Use BIND_IMMEDIATE so that undefined symbols cause a failure
return
* from shl_load(), rather than an abort() later on when we attempt
to
* call the library!
*/
caddr_t handle = dlopen(filename,
RTLD_LAZY);
return (void *) handle;
}
int eatallfds(void) {
int i = 0;
int j, myfd;
while (1) {
myfd = dup(0);
if (myfd 0) {
fprintf (stderr, dup() failed: %s\n,
strerror(errno));
break;
}
if (i = size) {
size *= 2;
fd = realloc(fd, size * sizeof(*fd));
if (fd == NULL) {
fprintf (stderr, Can't allocate: %s\n,
strerror(errno));
fprintf (stderr, Had used %d
descriptors\n,
i);
exit(1);
}
}
fd[i++] = myfd;
}
for (j = 0 ; j i ; ++j) {
close(fd[j]);
}
return i;
}
int main (int argc, char *argv[]) {
int n, na;
int i;
void *addr;
size = 3072;
fd = malloc((size + 1) * sizeof(*fd));
if (fd == NULL) {
fprintf (stderr, Can't allocate: %s\n, strerror(errno));
return 1;
}
n = eatallfds();
printf (Was able to use %d file descriptors\n, n);
na = 0;
for (i = 1 ; i argc ; ++i) {
addr = pg_dlopen(argv[i]);
if (addr != NULL) na++;
}
n = eatallfds();
printf (Was able to use %d file descriptors after opening %d
shared libs\n, n, na);
return 0;
}
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
pgp0.pgp
Description: PGP signature
Re: [HACKERS] Too-many-files errors on OS X
--On Monday, February 23, 2004 04:52:09 -0800 Kevin Brown [EMAIL PROTECTED] wrote: Larry Rosenman wrote: I had to hack on the code some more for FreeBSD: (the realloc call needed the multiplication). I ran this same code on UnixWare. I feel like a moron, having missed that. Probably explains the bad file number error I was getting on AIX, too... It was a coredump for me, which is why I had to look at it, and it took a while :-) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Hey, ya! =))
It was a virus, FWIW. w32/[EMAIL PROTECTED] LER --On Monday, March 01, 2004 14:48:14 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: removed from the mailing lists On Mon, 1 Mar 2004 [EMAIL PROTECTED] wrote: I don't bite, weah! pass: 74574 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Hey, ya! =))
--On Monday, March 01, 2004 15:02:50 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: are you and larryr the same person? *scratch head* No, but when I got the file, I fed it to www.webimmune.net and after feeding the .zip the password from the message, it told me that it was a virus. LER On Mon, 1 Mar 2004, Larry Rosenman wrote: It was a virus, FWIW. w32/[EMAIL PROTECTED] LER --On Monday, March 01, 2004 14:48:14 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: removed from the mailing lists On Mon, 1 Mar 2004 [EMAIL PROTECTED] wrote: I don't bite, weah! pass: 74574 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Hey, ya! =))
--On Monday, March 01, 2004 15:19:17 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: On Mon, 1 Mar 2004, Larry Rosenman wrote: --On Monday, March 01, 2004 15:02:50 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: are you and larryr the same person? *scratch head* No, but when I got the file, I fed it to www.webimmune.net and after feeding the .zip the password from the message, it told me that it was a virus. okay, if I'm reading you right here, this is one that virus checkers wouldn't pick up?? or is clamav's signatures just not updated yet? :( I had to pick up an extra.dat for McAfee, and this is BRAND NEW (3/1/4). I don't think ClamAV's been updated yet for it. LER LER On Mon, 1 Mar 2004, Larry Rosenman wrote: It was a virus, FWIW. w32/[EMAIL PROTECTED] LER --On Monday, March 01, 2004 14:48:14 -0400 Marc G. Fournier [EMAIL PROTECTED] wrote: removed from the mailing lists On Mon, 1 Mar 2004 [EMAIL PROTECTED] wrote: I don't bite, weah! pass: 74574 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- 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 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads flags...
I attempted(!) to compile up CVS Head, and if you --enable-thread-safety, you need to include the THREADS stuff to cc: gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port' cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport -o initdb Undefined first referenced symbol in file pthread_getspecific libpq.so pthread_key_create libpq.so pthread_oncelibpq.so pthread_setspecific libpq.so UX:ld: ERROR: Symbol referencing errors. No output written to initdb gmake[3]: *** [initdb] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin/initdb' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 $ Otherwise we don't pick up the threads library where the pthread_* routines are defined. (I sent the defines we need in src/template/unixware to Bruce already). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads flags...
On Thu, 18 Mar 2004, Larry Rosenman wrote: I attempted(!) to compile up CVS Head, and if you --enable-thread-safety, you need to include the THREADS stuff to cc: gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port' cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport -o initdb Undefined first referenced symbol in file pthread_getspecific libpq.so pthread_key_create libpq.so pthread_oncelibpq.so pthread_setspecific libpq.so UX:ld: ERROR: Symbol referencing errors. No output written to initdb gmake[3]: *** [initdb] Error 1 I bring this up on PGHACKERS because unixware may not be the only place we have to use the threads flags. What is the concensus of the community? LER ---(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] UnixWare/CVS Tip/initdb.c needs to use threads
--On Thursday, March 18, 2004 19:39:56 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: What is the concensus of the community? AFAICS, initdb should not need to depend on libpq in the first place; it never makes a connection to a live postmaster. I think it would be cleaner to get rid of that dependency instead of propagating thread junk into initdb. That's why I asked :) LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
--On Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: On Thu, 18 Mar 2004, Larry Rosenman wrote: I attempted(!) to compile up CVS Head, and if you --enable-thread-safety, you need to include the THREADS stuff to cc: gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port' cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport -o initdb Undefined first referenced symbol in file pthread_getspecific libpq.so pthread_key_create libpq.so pthread_oncelibpq.so pthread_setspecific libpq.so UX:ld: ERROR: Symbol referencing errors. No output written to initdb gmake[3]: *** [initdb] Error 1 I bring this up on PGHACKERS because unixware may not be the only place we have to use the threads flags. What is the concensus of the community? I tried removing the libpq link for initdb and got: (3) gmake gmake -C ../../../src/interfaces/libpq all gmake[1]: Entering directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq' gmake -C ../../../src/port all gmake[1]: Entering directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port' gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align initdb.o -L../../../src/port -L/usr/local/lib -L/usr/contrib/lib -Wl,-rpath,/usr/local/pgsql/lib -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align -lssl -lcrypto -lz -lreadline -ltermcap -lgetopt -lcompat -lipc -ldl -lm -lutil -lpgport -o initdb initdb.o: In function `get_encoding_id': initdb.o(.text+0x739): undefined reference to `pg_char_to_encoding' initdb.o(.text+0x74b): undefined reference to `pg_valid_server_encoding' initdb.o: In function `trapsig': initdb.o(.text+0x2212): undefined reference to `pqsignal' initdb.o: In function `main': initdb.o(.text+0x2e69): undefined reference to `pqsignal' initdb.o(.text+0x2e7b): undefined reference to `pqsignal' initdb.o(.text+0x2e8a): undefined reference to `pqsignal' initdb.o(.text+0x2e9c): undefined reference to `pqsignal' initdb.o(.text+0x2ea8): more undefined references to `pqsignal' follow gmake: *** [initdb] Error 1 I thought that once you include libpthread in libpq, that you don't have to mention it again then you use libpq. Is your platform different somehow in this regard? I seem to remember this problem with libcrypt and libpq. Is this the same problem? I see that initdb is just the first of many /bin programs to be compiled, so if we have to add the thread lib, we will have to do it for all the bin programs. Yikes. Why wasn't this a problem for 7.4? 7.4 had initdb as a Shell Script. the 7.4.x libpq didn't have any pthread_* references in it, that I see on my box. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] UnixWare/CVS Tip/initdb.c needs to use threads
--On Thursday, March 18, 2004 22:47:39 -0600 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: I see that initdb is just the first of many /bin programs to be compiled, so if we have to add the thread lib, we will have to do it for all the bin programs. Yikes. Why wasn't this a problem for 7.4? 7.4 had initdb as a Shell Script. the 7.4.x libpq didn't have any pthread_* references in it, that I see on my box. more info: /home/ler/pg-prod/postgresql-7.4.2/src/interfaces/libpq: $ grep pthread_ *.c thread.c: * strerror(). Other operating systems use pthread_setspecific() thread.c: * and pthread_getspecific() internally to allow standard library thread.c: * use pthread_setspecific/pthread_getspecific() also have *_r versions thread.c: * getpwuid() calls pthread_setspecific/pthread_getspecific() to return thread.c: static pthread_mutex_t strerror_lock = PTHREAD_MUTEX_INITIALIZER; thread.c: pthread_mutex_lock(strerror_lock); thread.c: pthread_mutex_unlock(strerror_lock); thread.c: static pthread_mutex_t getpwuid_lock = PTHREAD_MUTEX_INITIALIZER; thread.c: pthread_mutex_lock(getpwuid_lock); thread.c: pthread_mutex_unlock(getpwuid_lock); thread.c: static pthread_mutex_t gethostbyname_lock = PTHREAD_MUTEX_INITIALIZER; thread.c: pthread_mutex_lock(gethostbyname_lock); thread.c: pthread_mutex_unlock(gethostbyname_lock); $ nm libpq.so | grep pthread $ /home/ler/pg-dev/pgsql-server/src/interfaces/libpq: (7.5-dev): $ nm libpq.so | grep pthread_ [271] |0 |0 |NOTY |GLOB |0|UNDEF |pthread_getspecific [370] |0 |0 |NOTY |GLOB |0|UNDEF |pthread_key_create [421] |0 |0 |NOTY |GLOB |0|UNDEF |pthread_once [434] |0 |0 |NOTY |GLOB |0|UNDEF |pthread_setspecific $ grep pthread_ *.c fe-connect.c: static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT; fe-connect.c: pthread_once(check_sigpipe_once, check_sigpipe_handler); fe-print.c: pthread_setspecific(thread_in_send, t); fe-print.c: pthread_setspecific(thread_in_send, f); fe-secure.c:pthread_key_t thread_in_send; fe-secure.c:pthread_setspecific(thread_in_send, t); fe-secure.c:pthread_setspecific(thread_in_send, f); fe-secure.c:pthread_key_create(thread_in_send, NULL); fe-secure.c:return (pthread_getspecific(thread_in_send) /* has it been set? */ fe-secure.c:*(char *)pthread_getspecific(thread_in_send) == 't') ? true : false; thread.c: * strerror(). Other operating systems use pthread_setspecific() thread.c: * and pthread_getspecific() internally to allow standard library thread.c: * use pthread_setspecific/pthread_getspecific() also have *_r versions thread.c: * getpwuid() calls pthread_setspecific/pthread_getspecific() to return $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
--On Monday, March 22, 2004 09:52:54 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: Bruce Momjian wrote: Larry Rosenman wrote: The a.out (not any library) should be linked with -Kpthread (not -lpthread). This will force libthread to be linked in the right order relative to libc, libC, networking libraries, etc. In other words, the entire application either is or is not linked with threads; it's not a property of an individual library. SO, IF we are using the threads flags, we need to use them on ALL libpq-using programs, ours or the users. Seems we have a few options for making threaded libpq on Unixware: o remove thread-safe SIGPIPE code, which calls thread library o create a threaded and non-threaded libpq library o add a libpq function that enables threading, and do dynamic linking of thread calls based on that function o Add thread flags to all builds on that platform, including the backend o Add the ability to specify compile/link flags for everything but the backend As I remember, libcrypt used to be required by all libpq builds on various platforms. This seems to be a similar case. I think the last option might be the best. Somehow create different cppflags/libs for the backend and non-backend programs. One other option is to disable threads on this platform for 7.5 unless we find another platforms that need this to use threads. That is the direction I will take for the moment. If someone needs a threaded libpq on this platform, then can enable threads, compile libpq alone, and rename it with a thread extension. This will be a REGRESSION from 7.4. I object STRENUOUSLY to this tack. I want to see threads enabled for this platform since it is a threaded kernel. What do we have to do to get there? What code do I need to write for y'all? LER -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
--On Monday, March 22, 2004 12:33:56 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: One other option is to disable threads on this platform for 7.5 unless we find another platforms that need this to use threads. That is the direction I will take for the moment. If someone needs a threaded libpq on this platform, then can enable threads, compile libpq alone, and rename it with a thread extension. This will be a REGRESSION from 7.4. I object STRENUOUSLY to this tack. I want to see threads enabled for this platform since it is a threaded kernel. What do we have to do to get there? What code do I need to write for y'all? I have disabled the threading option for that platform. If someone else wants to work with Larry and the community on a solution, feel free. I am done for now, no matter how much Larry STRENUOUSLY objects. Why so nasty? If you didn't know, I was RIF'd from Internet America on Friday, and have some free time available to code for a bit. I really, really, really want to see threads enabled for libpq for this platform, especially since SCO will be distributing it at some point in time. What code do we need? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
--On Monday, March 22, 2004 12:49:00 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: I really, really, really want to see threads enabled for libpq for this platform, especially since SCO will be distributing it at some point in time. I think very few of the folks on this list will see that as a reason why they should expend any effort; more likely the opposite. If you can fix it yourself in a reasonably non-intrusive way, we'll take the patch ... that's about the extent of the cooperation you can expect. would a dlsym-based solution be accepted? I.E. wrap the pthread_* calls in libpq, and if the real ones are present, use them, else return a static variable? regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [PATCHES] [HACKERS] UnixWare/CVS Tip/initdb.c needs to use
--On Monday, March 22, 2004 13:15:15 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: --On Monday, March 22, 2004 12:49:00 -0500 Tom Lane [EMAIL PROTECTED]=20 wrote: If you can fix it yourself in a reasonably non-intrusive way, we'll take the patch ... that's about the extent of the cooperation you can expect. would a dlsym-based solution be accepted? I.E. wrap the pthread_* calls in libpq, and if the real ones are present, use them, else return a static=20 variable? I can't tell from that description if the idea meets the non intrusive test or not. How many places would you have to touch? How exactly are you going to tell whether the real ones are present? I'll gen up a patch this week and present it for review. Basically the 3 pthread_* calls that were added for thread-safe pipes would be wrapped, and dlsym returning NULL would mean the real ones are not present, per the note I got back from Dave Prosser of SCO, as well as the paper Jonathan Schilling pointed me to, that I posted the URL to on Friday before my world got rocked. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Basically, as things set right now in CVS, Unixware is ready to go because it thread for everything. We don't have per-template thread settings anymore because we test all of it in configure. Was a change made to link initdb et al with -Kpthread? It doesn't seem to be in AnonCVS yet. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 11:44:59 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: -- Start of PGP signed section. --On Thursday, May 13, 2004 10:05:22 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Basically, as things set right now in CVS, Unixware is ready to go because it thread for everything. We don't have per-template thread settings anymore because we test all of it in configure. Was a change made to link initdb et al with -Kpthread? It doesn't seem to be in AnonCVS yet. Really? You are configuring with --enable-thread-safety? I just updated your template in CVS, and it is attached. However, any old CVS should work fine. Nope, initdb is where we still die: cc -O -Kinline initdb.o exec.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport -o initdb Undefined first referenced symbol in file pthread_mutex_unlocklibpq.so pthread_getspecific libpq.so pthread_mutex_lock libpq.so pthread_key_create libpq.so pthread_oncelibpq.so pthread_setspecific libpq.so UX:ld: ERROR: Symbol referencing errors. No output written to initdb gmake[3]: *** [initdb] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src' gmake: *** [all] Error 2 $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] threads stuff/UnixWare
At the risk of getting my butt kicked again, is there any way we can talk about how to deal with threads on UnixWare and the libpq stuff? Has any other platform come up with a need to look for the real pthread_* calls from libpq? I would REALLY like us to support threaded programs in UnixWare, and would like to NOT antagonize the community, but would like to have a direction I can go to make this happen in 7.5 before we freeze. 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 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] threads stuff/UnixWare
--On Wednesday, May 12, 2004 12:57:10 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: At the risk of getting my butt kicked again, is there any way we can talk about how to deal with threads on UnixWare and the libpq stuff? Has any other platform come up with a need to look for the real pthread_* calls from libpq? I would REALLY like us to support threaded programs in UnixWare, and would like to NOT antagonize the community, but would like to have a direction I can go to make this happen in 7.5 before we freeze. Perfect time to start talking about it, at least :) Do you have a proposed patch to look at for doing this? No, as I believe the way I want to do it was frowned upon. I'd LIKE to be able to have PG wrappers for those functions, and have the first invocation of them look via dlsym() for the real ones, and if they are NOT there, use fake functions that assume we are NOT threaded. If they ARE present, indirect to the real functions. I am looking for direction before expending a lot of effort on it, if it will ultimately be rejected. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: At the risk of getting my butt kicked again, is there any way we can talk about how to deal with threads on UnixWare and the libpq stuff? In what way does the current thread stuff not work for you? regards, tom lane In the initdb compile: Undefined first referenced symbol in file pthread_mutex_unlocklibpq.so pthread_getspecific libpq.so pthread_mutex_lock libpq.so pthread_key_create libpq.so pthread_oncelibpq.so pthread_setspecific libpq.so UX:ld: ERROR: Symbol referencing errors. No output written to initdb gmake[3]: *** [initdb] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src' gmake: *** [all] Error 2 $ -- 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] threads stuff/UnixWare
--On Wednesday, May 12, 2004 14:14:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: I'd LIKE to be able to have PG wrappers for those functions, and have the first invocation of them look via dlsym() for the real ones, and if they are NOT there, use fake functions that assume we are NOT threaded. Wouldn't it be easier to have a #define? Correct me if I'm wrong here, but the problem is that we are expecting thread functinos to be called x_, while Unixware defines them as pthread_, right? so make Unixware specific #defines that map x_ to pthread_ ... No, we are expecting them to have pthread_*. On UnixWare, to get the pthread_* functions, you need to invoke a compiler option (-Kpthread), to cause libpthread to be linked in. Since libpq.so now REQUIRES the function, we need to either: 1) force ANY program that uses libpq to be compiled/linked with -Kpthread or 2) dynamically determine if libpthread is loaded and use the real pthread_* functions if they are there (libpthread is in the image), or use fake singlethread versions of the pthread_* calls if libpthread is NOT in the image. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- 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 8: explain analyze is your friend
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 13:18:35 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: --On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane [EMAIL PROTECTED] In what way does the current thread stuff not work for you? In the initdb compile: Undefined first referenced symbol in file pthread_mutex_unlocklibpq.so pthread_getspecific libpq.so pthread_mutex_lock libpq.so pthread_key_create libpq.so pthread_oncelibpq.so pthread_setspecific libpq.so Hmm. And that means what? Does Unixware not have these functions? Are we just failing to suck in the needed library? regards, tom lane No, we don't pass the -Kpthread (thread CFLAGS) to the C links. This is the whole discussion we had back in January/February about forcing -Kpthread for *ALL* libpq using programs, or dynamically determining if the image already is linked -Kpthread, or not supporting threads at all on UW. #3 is unacceptable to me. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 15:02:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: --On Wednesday, May 12, 2004 14:14:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: I'd LIKE to be able to have PG wrappers for those functions, and have the first invocation of them look via dlsym() for the real ones, and if they are NOT there, use fake functions that assume we are NOT threaded. Wouldn't it be easier to have a #define? Correct me if I'm wrong here, but the problem is that we are expecting thread functinos to be called x_, while Unixware defines them as pthread_, right? so make Unixware specific #defines that map x_ to pthread_ ... No, we are expecting them to have pthread_*. On UnixWare, to get the pthread_* functions, you need to invoke a compiler option (-Kpthread), to cause libpthread to be linked in. Since libpq.so now REQUIRES the function, we need to either: 1) force ANY program that uses libpq to be compiled/linked with -Kpthread Ummm, shouldn't that be added to the port specific Makefile? See my reply to Tom. It forces ALL libpq using programs to be linked with -Kpthread, which was deemed unacceptable. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 15:39:34 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: --On Wednesday, May 12, 2004 15:02:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: --On Wednesday, May 12, 2004 14:14:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: I'd LIKE to be able to have PG wrappers for those functions, and have the first invocation of them look via dlsym() for the real ones, and if they are NOT there, use fake functions that assume we are NOT threaded. Wouldn't it be easier to have a #define? Correct me if I'm wrong here, but the problem is that we are expecting thread functinos to be called x_, while Unixware defines them as pthread_, right? so make Unixware specific #defines that map x_ to pthread_ ... No, we are expecting them to have pthread_*. On UnixWare, to get the pthread_* functions, you need to invoke a compiler option (-Kpthread), to cause libpthread to be linked in. Since libpq.so now REQUIRES the function, we need to either: 1) force ANY program that uses libpq to be compiled/linked with -Kpthread Ummm, shouldn't that be added to the port specific Makefile? See my reply to Tom. It forces ALL libpq using programs to be linked with -Kpthread, which was deemed unacceptable. deemed unacceptable by whom? Sounds to me alot simpler of a solution then making wrappers for the pthread_* functions just to accommodate one OS ... I could see it if this was a wide-spread problem, but it doesn't appear to be ... Bruce didn't want to muck ip all the .c programs in the distribution to do that. As well as any users using libpq. I'm all ears if the COMMUNITY wants to do it. LER Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 15:59:19 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: Ummm, shouldn't that be added to the port specific Makefile? See my reply to Tom. It forces ALL libpq using programs to be linked with -Kpthread, which was deemed unacceptable. deemed unacceptable by whom? Sounds to me alot simpler of a solution then making wrappers for the pthread_* functions just to accommodate one OS ... I could see it if this was a wide-spread problem, but it doesn't appear to be ... Bruce didn't want to muck ip all the .c programs in the distribution to do that. I'm confused now ... what .c programs would have to be mucked up if you add -Kpthread to the Unixware specific Makefile? initdb, et al. See these comments in src/template/unixware: # Disabled because flags are required for all apps using libpq. # Waiting to see if other platforms need this too. 2004-03-22 THREAD_SUPPORT=yes # verified UnixWare 7.1.4 2004-03-18 STRERROR_THREADSAFE=yes GETPWUID_THREADSAFE=yes GETHOSTBYNAME_THREADSAFE=yes $ I turned it back on to see if the new stuff had fixed it. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: This is the whole discussion we had back in January/February about forcing -Kpthread for *ALL* libpq using programs, or dynamically determining if the image already is linked -Kpthread, or not supporting threads at all on UW. Oh, that business :-(. AFAIR we did not much care for any of the proposed alternatives. Have you thought of any new options? At this point I'd settle for saying that --enable-thread-safety on Unixware will generate a library that requires -Kpthread. This is kinda grungy but it seems that any more-pleasant solution would require a disproportionate amount of work. If I did the work for the dlsym() stuff would you and the rest of core@ accept 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 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: --On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane [EMAIL PROTECTED]=20 wrote: At this point I'd settle for saying that --enable-thread-safety on Unixware will generate a library that requires -Kpthread. This is kinda grungy but it seems that any more-pleasant solution would require a disproportionate amount of work. If I did the work for the dlsym() stuff would you and the rest of core@ accept it? How invasive a change are we talking about? I'd be inclined to reject a patch that makes libpq materially less readable ... regards, tom lane I was thinking of pq_pthread_* calls, and that function would set a static flag for calling either the real pthread_* function or a statically named version in libpgport.a that is a single thread wrapper. I know, this sucks, but, I don't see any other way, other than linking *ALL* libpq-using programs (including initdb and friends) with -K pthread. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 16:22:58 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: I was thinking of pq_pthread_* calls, and that function would set a static flag for calling either the real pthread_* function or a statically named version in libpgport.a that is a single thread wrapper. And how will you avoid having a link-time dependency on the real pthread function? You muttered about dlsym but how much code will that take, and what kind of runtime penalty will we incur? (IIRC the pthread functions are performance critical.) The first call to ANY of the pthread_* functions would set the flag, and would cache the dlsym() info. Even more to the point, can you make it work at all? I seem to recall from the prior discussion that -Kpthread actually changes some code generation details on that platform. Are -Kpthread and non -Kpthread libraries interoperable at all? Yes, this is how libc deals with it. We wouldn't have a hard symbol for the pthread_* calls. I can ask the compiler guys at SCO if you want. I know, this sucks, but, I don't see any other way, other than linking *ALL* libpq-using programs (including initdb and friends) with -K pthread. -Kpthread doesn't sound that bad to me, as long as it's documented. regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 17:29:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 12 May 2004, Larry Rosenman wrote: --On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: --On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane [EMAIL PROTECTED]=20 wrote: At this point I'd settle for saying that --enable-thread-safety on Unixware will generate a library that requires -Kpthread. This is kinda grungy but it seems that any more-pleasant solution would require a disproportionate amount of work. If I did the work for the dlsym() stuff would you and the rest of core@ accept it? How invasive a change are we talking about? I'd be inclined to reject a patch that makes libpq materially less readable ... regards, tom lane I was thinking of pq_pthread_* calls, and that function would set a static flag for calling either the real pthread_* function or a statically named version in libpgport.a that is a single thread wrapper. I know, this sucks, but, I don't see any other way, other than linking *ALL* libpq-using programs (including initdb and friends) with -K pthread. k, a change that 'sucks', vs linking against -Kpthread ... I'm for the -Kpthread route myself, which still sounds the 'clean' solution ... that was rejected back in Jan-Mar. BUT, I agree it would work. I tried to submit the patch, and it was killed. LER Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
[HACKERS] UnixWare/Threads stuff [repost from March]
This is a re-post, and still the state of things. There were a few posts after this because of my STRENUOUS objection below. I still think we should enable threads somehow on this platform. --On Monday, March 22, 2004 11:14:59 -0600 Larry Rosenman [EMAIL PROTECTED] wrote: --On Monday, March 22, 2004 09:52:54 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: Bruce Momjian wrote: Larry Rosenman wrote: The a.out (not any library) should be linked with -Kpthread (not -lpthread). This will force libthread to be linked in the right order relative to libc, libC, networking libraries, etc. In other words, the entire application either is or is not linked with threads; it's not a property of an individual library. SO, IF we are using the threads flags, we need to use them on ALL libpq-using programs, ours or the users. Seems we have a few options for making threaded libpq on Unixware: o remove thread-safe SIGPIPE code, which calls thread library o create a threaded and non-threaded libpq library o add a libpq function that enables threading, and do dynamic linking of thread calls based on that function o Add thread flags to all builds on that platform, including the backend o Add the ability to specify compile/link flags for everything but the backend As I remember, libcrypt used to be required by all libpq builds on various platforms. This seems to be a similar case. I think the last option might be the best. Somehow create different cppflags/libs for the backend and non-backend programs. One other option is to disable threads on this platform for 7.5 unless we find another platforms that need this to use threads. That is the direction I will take for the moment. If someone needs a threaded libpq on this platform, then can enable threads, compile libpq alone, and rename it with a thread extension. This will be a REGRESSION from 7.4. I object STRENUOUSLY to this tack. I want to see threads enabled for this platform since it is a threaded kernel. What do we have to do to get there? What code do I need to write for y'all? LER -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] UnixWare/Threads stuff [repost from March]
--On Wednesday, May 12, 2004 22:14:33 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: I don't see a patch in here ... forget to attach it? It was way back in the thread, and this was the upshot of the discussion. See the note I just replied to Bruce with. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 21:08:25 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: Please save us all time searching by providing a URL ... I can't find my posts on archives.postgresql.org, but can find it in MY archives. Well, then we won't be able to find 'em either, so please repost. This is heading down the same path I was back on 3/22. I think at the time we were hoping for a cleaner solution. Since none has emerged, it would be good of you to refresh our memories of where things stood. [ Sorry I have been away from email today. ] Larry, now that I have put the thread testing into configure, I am ready to deal with Unixware. In fact I posted to the list asking you about it but was too lazy to look up your email address. Anyway, I think the only solution is going to be to use the -K flag on all compiles on that platform if you want threads, so anything that uses libpq will need it. We don't have a client-level flags option at this point, but we can add it, or just the flag for the backend compile too. I think a client-level flag would be best, that way the backend doesn't get the wrapped functions from libthread. Can you do the patch? I think that is our best option. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 21:55:40 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: [ Sorry I have been away from email today. ] Larry, now that I have put the thread testing into configure, I am ready to deal with Unixware. In fact I posted to the list asking you about it but was too lazy to look up your email address. Anyway, I think the only solution is going to be to use the -K flag on all compiles on that platform if you want threads, so anything that uses libpq will need it. We don't have a client-level flags option at this point, but we can add it, or just the flag for the backend compile too. I think a client-level flag would be best, that way the backend doesn't get the wrapped functions from libthread. Can you do the patch? OK. Can someone think of a clean way to add a flag to everything but the backend build? Hold, what about /port. Larry, if we compile anything with threads does everything that links with that object file require the flag, even if there are no thread flags in the object file? I don't think so, but I am just checking. Actually, my bet is that it might do that because if it didn't, there would be no problem with using that flag on the backend because there are no threading calls in there. Yes, there would still be the overhead, because the functions that libthread wraps would go through that overhead since libthread does it's magic at _ini time. Y'all were concerned with overhead in previous discussions. If you want to link the backend with -Kpthread, you can, but basically the client code (initdb, et al) should be -Kpthread, and the backend should NOT since there are no threads calls in the backend. I am afraid of libpgport. Those object files get used by the backend, and by the client stuff. Larry can -K and non-K object files be mixed in the same binary? Yes, they can. But, you MUST link ANY pthread_* using code with -K pthread. See above discussion. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Wednesday, May 12, 2004 22:26:03 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Larry Rosenman wrote: Yes, there would still be the overhead, because the functions that libthread wraps would go through that overhead since libthread does it's magic at _ini time. Y'all were concerned with overhead in previous discussions. If you want to link the backend with -Kpthread, you can, but basically the client code (initdb, et al) should be -Kpthread, and the backend should NOT since there are no threads calls in the backend. I am afraid of libpgport. Those object files get used by the backend, and by the client stuff. Larry can -K and non-K object files be mixed in the same binary? Yes, they can. But, you MUST link ANY pthread_* using code with -K pthread. OK, can someone come up with a cute way to add flags only to things that use libpq, meaning /interfaces and /bin? What about where -lpq is specified? (I'm NOT a GNU Make guru). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 09:54:02 +0200 Zeugswetter Andreas SB SD [EMAIL PROTECTED] wrote: I know, this sucks, but, I don't see any other way, other than linking *ALL* libpq-using programs (including initdb and friends) with -K pthread. How about making a libpq.so (without pthread) and a thread safe libpq_r.so ? That's against the way this platform does things. I.E. the only library is libc. All the other system supplied libs do the right thing in the presence or absence of libthread in the image. I did get a note from my SCO contacts that they are looking into how to make it easier for stuff to be threads ready, but I don't expect that to be ready for 7.5 release. The -Kpthread on all libpq using programs is the easiest way FOR NOW. Thanks, LER Andreas -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] threads stuff/UnixWare
--On Thursday, May 13, 2004 09:18:21 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: I did get a note from my SCO contacts that they are looking into how to make it easier for stuff to be threads ready, but I don't expect that to be ready for 7.5 release. The -Kpthread on all libpq using programs is the easiest way FOR NOW. Hmm. If there is work happening at the platform level to improve matters, then I'd definitely vote for taking the simplest solution (ie -Kpthread everywhere) for now. We can always do all that other work later if nothing gets fixed; but why invest a lot of work for what might be only a short-term problem? I agree. the only issue is how to set up our makefiles to only do the -Kpthread/-pthreads(gcc) flags on the client code, and not do it for the backend itself. regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] hacker help: PHP-4.2.3 patch to allow restriction of
On Thu, 2002-09-26 at 22:42, Tom Lane wrote: Jim Mercer [EMAIL PROTECTED] writes: as best i can understand, there is no way to get apach/php/pgsql configured (using PostgreSQL's native access mappings) that would disallow php code in one virtual host from connecting to any database on the system. Betraying my ignorance of PHP here: what does a server supporting multiple virtual hosts look like from the database's end? Can we tell the difference at all between connections initiated on behalf of one virtual host from those initiated on behalf of another? Nope, you can't to the best of my knowledge. You just get a standard connect string. (Assuming NAME based vHosts here, which is what most should be, modulo SSL based ones). [snip] -- 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] cross-posts (was Re: [GENERAL] Large databases,
On Sun, 2002-10-06 at 22:20, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: ... Avoiding cross-posting would be nice, since I am getting lots of duplicate messages these days. Cross-posting is a fact of life, and in fact encouraged, on the pg lists. I suggest adapting. Try sending set all unique your-email-address to the PG majordomo server; this sets you up to get only one copy of each cross-posted message. That doesn't seem to work any more: set all unique [EMAIL PROTECTED] The all mailing list is not supported at PostgreSQL User Support Lists. What do I need to send now? Marc? -- 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] cross-posts (was Re: [GENERAL] Large databases,
On Mon, 2002-10-07 at 07:01, Michael Paesold wrote: On Sun, 2002-10-06 at 22:20, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: ... Avoiding cross-posting would be nice, since I am getting lots of duplicate messages these days. Cross-posting is a fact of life, and in fact encouraged, on the pg lists. I suggest adapting. Try sending set all unique your-email-address to the PG majordomo server; this sets you up to get only one copy of each cross-posted message. That doesn't seem to work any more: set all unique [EMAIL PROTECTED] The all mailing list is not supported at PostgreSQL User Support Lists. What do I need to send now? Marc? it is: set ALL unique your-email if you also don't want to get emails that have already been cc'd to you, you can use: set ALL eliminatecc your-email for a full list of set options send: help set to majordomo. Thanks. That worked great. (I use Mailman, and didn't realize the ALL needed to be capitalized. 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] v7.3 Branched ...
On Wed, 2002-10-16 at 16:05, Rod Taylor wrote: On Wed, 2002-10-16 at 16:56, Robert Treat wrote: Perhaps one could just create a PostgreSQL Powertools section on techdocs, naming the packages and where to get them. This would eliminate the need to maintain a package that just duplicates other packages... Let ye-old package managers make a shell package which simply points to the others as dependencies. Sort of like a meta-port? I'd be willing to do this for FreeBSD (think Sean? would help as well) if someone comes up with the list. That would be useful, and port(s) for the rest of contrib as well (like contrib/tsearch). :-) -- 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] pg_dump and large files - is this a problem?
On Mon, 2002-10-21 at 20:47, Bruce Momjian wrote: Here is a modified version of Philip's patch that has the changes Tom suggested; treating off_t as an integral type. I did light testing on my BSD/OS machine that has 8-byte off_t but I don't have 4 gigs of free space to test larger files. I can make an account for anyone that wants to play on UnixWare 7.1.3. -- 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] pg_dump and large files - is this a problem?
On Mon, 2002-10-21 at 20:52, Bruce Momjian wrote: Larry Rosenman wrote: On Mon, 2002-10-21 at 20:47, Bruce Momjian wrote: Here is a modified version of Philip's patch that has the changes Tom suggested; treating off_t as an integral type. I did light testing on my BSD/OS machine that has 8-byte off_t but I don't have 4 gigs of free space to test larger files. I can make an account for anyone that wants to play on UnixWare 7.1.3. If you have 7.3, you can just test this way: I haven't had the time to play with 7.3 (busy on a NUMBER of other things). I'm more than willing to supply resources, just my time is short right now. 1) apply the patch 2) run the regression tests 3) pg_dump -Fc regression /tmp/x 4) pg_restore -Fc /tmp/x That's all I did and it worked. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...
Without specifying the -Xb switch to kill the C99 interpretation of inline, I get the following from current CVS: UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1856: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1870: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1872: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1885: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1897: inline functions cannot use static identifier: myFunctionCall2 -- 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
[HACKERS] UnixWare 7.1.3 (BETA), compile error (with cc -Xb)
before or at: return UX:acomp: ERROR: ascii_and_mic.c, line 48: parameter not in identifier list: Datum UX:acomp: ERROR: ascii_and_mic.c, line 48: Syntax error before or at: 0 UX:acomp: WARNING: ascii_and_mic.c, line 48: syntax error: empty declaration UX:acomp: ERROR: ascii_and_mic.c, line 52: parameter not in identifier list: Datum UX:acomp: ERROR: ascii_and_mic.c, line 53: parameter not in identifier list: mic_to_ascii UX:acomp: ERROR: ascii_and_mic.c, line 54: parameter not in identifier list: src UX:acomp: ERROR: ascii_and_mic.c, line 54: cannot initialize parameter: src UX:acomp: ERROR: ascii_and_mic.c, line 54: left operand of - must be pointer to struct/union UX:acomp: WARNING: ascii_and_mic.c, line 54: assignment type mismatch UX:acomp: ERROR: ascii_and_mic.c, line 55: parameter not in identifier list: dest UX:acomp: ERROR: ascii_and_mic.c, line 55: cannot initialize parameter: dest UX:acomp: ERROR: ascii_and_mic.c, line 55: left operand of - must be pointer to struct/union UX:acomp: WARNING: ascii_and_mic.c, line 55: assignment type mismatch UX:acomp: ERROR: ascii_and_mic.c, line 56: parameter not in identifier list: len UX:acomp: ERROR: ascii_and_mic.c, line 56: cannot initialize parameter: len UX:acomp: ERROR: ascii_and_mic.c, line 56: left operand of - must be pointer to struct/union UX:acomp: ERROR: ascii_and_mic.c, line 56: function designator is not of function type UX:acomp: ERROR: ascii_and_mic.c, line 56: operands must have integral type: op UX:acomp: ERROR: ascii_and_mic.c, line 58: left operand of - must be pointer to struct/union UX:acomp: ERROR: ascii_and_mic.c, line 58: function designator is not of function type UX:acomp: ERROR: ascii_and_mic.c, line 58: operands must have integral type: op UX:acomp: ERROR: ascii_and_mic.c, line 59: left operand of - must be pointer to struct/union UX:acomp: ERROR: ascii_and_mic.c, line 59: function designator is not of function type UX:acomp: ERROR: ascii_and_mic.c, line 59: operands must have integral type: op UX:acomp: ERROR: ascii_and_mic.c, line 64: Syntax error before or at: 0 UX:acomp: ERROR: ascii_and_mic.c, line 65: cannot recover from previous errors gmake[3]: *** [ascii_and_mic.o] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/backend/utils/mb/conversion_procs' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 -- 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] UnixWare 7.1.3 (BETA), C99 compiler, current CVS,
On Sat, 2002-10-26 at 10:07, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: Without specifying the -Xb switch to kill the C99 interpretation of inline, I get the following from current CVS: UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use static identifier: myFunctionCall2 I don't understand what it's unhappy about. My C99 draft sez [#6] Any function with internal linkage can be an inline function. so the text of the message is surely not what they are really complaining about? Or is the compiler broken? I'll ask, it is Beta (although the Compiler has done this since the C99 functionality was added, and it causes a LOT of open source stuff to require -Xb). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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] ECPG and bison
On Fri, 2002-10-18 at 13:51, Tom Lane wrote: Michael Meskes [EMAIL PROTECTED] writes: those now, you can, because I assume your bison 1.50 output will get into CVS. I have bison 1.50 here too. The changes are there already, I just have to fold the ecpg.big branch into HEAD. Probably you should refrain from doing that until Marc installs 1.50 at postgresql.org, else the nightly snapshots will be broken, to no one's advantage. Marc, can you do something about installing bison 1.50 soon? (Guess I'd better get it loaded on my own machines, too...) Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly by). 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 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] ECPG and bison
On Fri, 2002-10-18 at 22:03, Marc G. Fournier wrote: On Fri, 18 Oct 2002, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Larry Rosenman wrote: Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly by). I can confirm that: http://ftp.gnu.org/gnu/bison/ Attached is the Changelog since 1.50. Urgh. Nothing like major releases 2 weeks apart to give one a nice warm comfy feeling about the stability of one's tools. Offhand it looks like these are nearly all bug fixes, and so we'd better standardize on 1.75 not 1.50. But I wonder what will be out next week... that's one of hte reasons I've been holding off (the other being a busy week) ... I *try* to keep stuff like this to what the FreeBSD ports collection considers a stable release, and it hasn't been updated yet :( The PR I referred to above is the PR to update to 1.75. -- 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] Please help
On Mon, 2002-10-21 at 12:57, Larry Rosenman wrote: On Mon, 2002-10-21 at 12:39, Olivier PRENANT wrote: Hi larry, Glad to see you around... On 21 Oct 2002, Larry Rosenman wrote: Date: 21 Oct 2002 12:34:48 -0500 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Tom Lane [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: [HACKERS] Please help The point is, it occurs today for the very first time! Question: does (with 7.2) augmenting max_connection suffice, or do I have to recompile? You might need to up the Shared Memory parameters and the Semaphore Parameters in your OS (UnixWare IIRC). I did! Ok. That's the only thing that comes to my mind! I changed max_coneections (and related parameters) in postgresql.conf only... I say that, because I tried to change socket_directory in postgresql.conf and clients didn't work anymore Sorry, I mis-explain! I mean changing socket_directory in postgresql.conf and restart server did create .s.PGSQL.5432 in the new dir, however clients (like psql) still want it in /tmp!! That **WOULD** take a recompile. Or (IIRC), changing the connect string passed from PHP to PostgreSQL. LER See above. regards, tom lane -- 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) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 ---(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 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] UnixWare 7.1.3: with current CVS, and cc -Xb.,..
We pass all regression test. this is UnixWare 7.1.3, with the native cc compiler. -- 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] assignment type mismatch complaints
How concerned are we about assignment type mismatch warnings? I got a bunch in the mb stuff, and some in other places from the UnixWare 7.1.3 compiler. We still pass all regression tests. 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] 7.3b3 ok on unixware 71[12] here
On Wed, 2002-10-30 at 12:16, Olivier PRENANT wrote: On 30 Oct 2002, Larry Rosenman wrote: Date: 30 Oct 2002 12:14:01 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] 7.3b3 ok on unixware 71[12] here I've got it running with 5.8.0 of Perl. Is there anything holding you back from updating to 5.8.0 of PERL? Unfortunatly yes! Majordomo2 doesn't work quit well with 580. Is there anyway to ake 561 compile the way 580 does for dynaloader? I had zero luck... Sorry. 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] Please help
On Mon, 2002-10-21 at 12:39, Olivier PRENANT wrote: Hi larry, Glad to see you around... On 21 Oct 2002, Larry Rosenman wrote: Date: 21 Oct 2002 12:34:48 -0500 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Tom Lane [EMAIL PROTECTED], pgsql-hackers list [EMAIL PROTECTED] Subject: Re: [HACKERS] Please help The point is, it occurs today for the very first time! Question: does (with 7.2) augmenting max_connection suffice, or do I have to recompile? You might need to up the Shared Memory parameters and the Semaphore Parameters in your OS (UnixWare IIRC). I did! Ok. That's the only thing that comes to my mind! I changed max_coneections (and related parameters) in postgresql.conf only... I say that, because I tried to change socket_directory in postgresql.conf and clients didn't work anymore Sorry, I mis-explain! I mean changing socket_directory in postgresql.conf and restart server did create .s.PGSQL.5432 in the new dir, however clients (like psql) still want it in /tmp!! That **WOULD** take a recompile. LER See above. regards, tom lane -- 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) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 ---(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] UnixWare 7.1.3: with current CVS, and cc -Xb.,..
On Sat, 2002-10-26 at 15:11, Bruce Momjian wrote: Updated: http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html the illustrious marketing folks at The SCO group (nee Caldera) have renamed this OS back to UnixWare. You may want to change the first column back to UnixWare. (and footnote that OpenUNIX 8.0.0 is really UnixWare 7.1.2). --- Larry Rosenman wrote: We pass all regression test. this is UnixWare 7.1.3, with the native cc compiler. -- 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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] assignment type mismatch complaints
On Sat, 2002-10-26 at 18:27, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: How concerned are we about assignment type mismatch warnings? They're probably all char versus unsigned char complaints? Probably. The first few I looked at are PG_GETARG_CSTRING to unsigned char assignments. (I can send the whole list to either you, Tom, or the list). There are a ton of them on compilers that care about it; most of 'em in the multibyte support. While it would be nice to clean up all that someday, I can't say that I think it's a really profitable use of time. Ok, I understand that. It seems that there are a bunch, but they are just warnings. One difficulty is that the obvious fix (add a bunch of casts) is probably a net degradation of the code. Explicit casts will hide mismatches that are a lot worse than char signedness, and so cluttering the code with them makes things more fragile IMHO. I think an acceptable fix would involve running around and changing datatype and function declarations; which is much more subtle and thought-requiring than throwing in a cast wherever the compiler burps. Understand, and I don't expect it to happen in a beta test :-). 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] assignment type mismatch complaints
On Sat, 2002-10-26 at 18:34, Larry Rosenman wrote: On Sat, 2002-10-26 at 18:27, Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: How concerned are we about assignment type mismatch warnings? They're probably all char versus unsigned char complaints? Probably. The first few I looked at are PG_GETARG_CSTRING to unsigned char assignments. (I can send the whole list to either you, Tom, or the list). There are a ton of them on compilers that care about it; most of 'em in the multibyte support. While it would be nice to clean up all that someday, I can't say that I think it's a really profitable use of time. Ok, I understand that. It seems that there are a bunch, but they are just warnings. One difficulty is that the obvious fix (add a bunch of casts) is probably a net degradation of the code. Explicit casts will hide mismatches that are a lot worse than char signedness, and so cluttering the code with them makes things more fragile IMHO. I think an acceptable fix would involve running around and changing datatype and function declarations; which is much more subtle and thought-requiring than throwing in a cast wherever the compiler burps. Understand, and I don't expect it to happen in a beta test :-). If anyone wants to look at these: ftp://ftp.lerctr.org/pub/pg-dev/gmake.out.txt Thanks, 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 ---(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
[HACKERS] FreeBSD 4.7: BETA3 (from port): regression failures...
60 ORDER BY unique1 LIMIT 5; five | unique1 | unique2 | stringu1 --+-+-+-- ! (0 rows) SELECT ''::text AS two, unique1, unique2, stringu1 FROM onek WHERE unique1 60 AND unique1 63 ORDER BY unique1 LIMIT 5; two | unique1 | unique2 | stringu1 -+-+-+-- ! (0 rows) SELECT ''::text AS three, unique1, unique2, stringu1 FROM onek WHERE unique1 100 ORDER BY unique1 LIMIT 3 OFFSET 20; three | unique1 | unique2 | stringu1 ---+-+-+-- ! (0 rows) SELECT ''::text AS zero, unique1, unique2, stringu1 FROM onek WHERE unique1 50 *** *** 54,110 ORDER BY unique1 DESC LIMIT 20 OFFSET 39; eleven | unique1 | unique2 | stringu1 +-+-+-- ! | 10 | 520 | KA ! | 9 | 49 | JA ! | 8 | 653 | IA ! | 7 | 647 | HA ! | 6 | 978 | GA ! | 5 | 541 | FA ! | 4 | 833 | EA ! | 3 | 431 | DA ! | 2 | 326 | CA ! | 1 | 214 | BA ! | 0 | 998 | AA ! (11 rows) SELECT ''::text AS ten, unique1, unique2, stringu1 FROM onek ORDER BY unique1 OFFSET 990; ten | unique1 | unique2 | stringu1 -+-+-+-- ! | 990 | 369 | CM ! | 991 | 426 | DM ! | 992 | 363 | EM ! | 993 | 661 | FM ! | 994 | 695 | GM ! | 995 | 144 | HM ! | 996 | 258 | IM ! | 997 | 21 | JM ! | 998 | 549 | KM ! | 999 | 152 | LM ! (10 rows) SELECT ''::text AS five, unique1, unique2, stringu1 FROM onek ORDER BY unique1 OFFSET 990 LIMIT 5; five | unique1 | unique2 | stringu1 --+-+-+-- ! | 990 | 369 | CM ! | 991 | 426 | DM ! | 992 | 363 | EM ! | 993 | 661 | FM ! | 994 | 695 | GM ! (5 rows) SELECT ''::text AS five, unique1, unique2, stringu1 FROM onek ORDER BY unique1 LIMIT 5 OFFSET 900; five | unique1 | unique2 | stringu1 --+-+-+-- ! | 900 | 913 | QI ! | 901 | 931 | RI ! | 902 | 702 | SI ! | 903 | 641 | TI ! | 904 | 793 | UI ! (5 rows) --- 42,67 ORDER BY unique1 DESC LIMIT 20 OFFSET 39; eleven | unique1 | unique2 | stringu1 +-+-+-- ! (0 rows) SELECT ''::text AS ten, unique1, unique2, stringu1 FROM onek ORDER BY unique1 OFFSET 990; ten | unique1 | unique2 | stringu1 -+-+-+-- ! (0 rows) SELECT ''::text AS five, unique1, unique2, stringu1 FROM onek ORDER BY unique1 OFFSET 990 LIMIT 5; five | unique1 | unique2 | stringu1 --+-+-+-- ! (0 rows) SELECT ''::text AS five, unique1, unique2, stringu1 FROM onek ORDER BY unique1 LIMIT 5 OFFSET 900; five | unique1 | unique2 | stringu1 --+-+-+-- ! (0 rows) == -- 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: [Fwd: Re: [HACKERS] UnixWare 7.1.3 (BETA), C99 compiler,
Dave,
Thanks for the details, I've copied this reply back to the PostgreSQL
guys as well.
LER
On Mon, 2002-10-28 at 09:00, Dave Prosser wrote:
Larry Rosenman wrote:
From: Tom Lane [EMAIL PROTECTED]
To: Larry Rosenman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] UnixWare 7.1.3 (BETA), C99 compiler, current CVS, error...
Date: 26 Oct 2002 11:07:13 -0400
Larry Rosenman [EMAIL PROTECTED] writes:
Without specifying the -Xb switch to kill the C99 interpretation of
inline, I get the following from current CVS:
UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use
static identifier: myFunctionCall2
I don't understand what it's unhappy about. My C99 draft sez
[#6] Any function with internal linkage can be an inline
function.
so the text of the message is surely not what they are really
complaining about? Or is the compiler broken?
There is a contraint (i.e., a diagnostic is required) in 6.7.4 Function Specifiers
that says:
An inline definition of a function with external linkage shall not contain a
definition of a modifiable object with static storage duration, and shall not
contain a reference to an identifier with internal linkage.
Line 1854 is
if (DatumGetBool(myFunctionCall2(sortFunction, datum1, datum2)))
where myFunctionCall2() is a static function defined above ApplySortFunction().
It's not the inlinedness--a word?--of myFunctionCall2() that's the problem,
it's that myFunctionCall2() is static and that ApplySortFunction() is inline'd.
You wrote in your follow up:
After reading a little further, it seems that the brain damage is in the
standard, not the compiler :-(. It looks like C99's notion of a
function that is both global and inline is that you must provide *two*
definitions of the function, one marked inline and one not; moreover,
these must appear in separate translation units. What in the world were
those people smoking? That's a recipe for maintenance problems (edit
one definition, forget to edit the other), not to mention completely at
variance with the de facto standard behavior of inline that's been
around for a long time.
The C committee's view of inline does not match the historic GCC one.
They were trying to find a middle ground that was fully compatible with
the C++ inline, while not requiring any fancy code generation tricks.
In other words, that C could still be compiled with a one-pass compiler.
The motivation for this restriction is to make sure that all instances
of an inline function that's visible outside of the compilation unit
are identical. Having the same sequence of tokens isn't good enough
if there are references to identifiers that could well be different in
differing compilation units.
Until the open source base (and GCC) get around to matching the C99
inline model, I generally attempt to compile open source with cc -Xb
as that eliminates recognition of inline as a keyword, and thus doesn't
get into the issues with the clashes between the two models.
My inclination is to change the code for ApplySortFunction to look like
#if defined(__GNUC__)
__inline__
#endif
int32
ApplySortFunction
so that the inline optimization only gets done for gcc, which we know
interprets inline sanely. Anyone see a better answer?
You've given us one source file. Is ApplySortFunction() really called
from other files? Another approach, assuming both this and that the
inlining is viewed as important for its three calls within this file,
to have a front end version of an internal function. To wit:
static inline int32
StaticApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
Datum datum1, bool isNull1,
Datum datum2, bool isNull2)
{
//etc.
}
int32
ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind,
Datum datum1, bool isNull1,
Datum datum2, bool isNull2)
{
return StaticApplySortFunction(sortFunction, kind, datum1, isNull1, datum2,
isNull2);
}
and change all the existing calls within tuplesort.c to use
StaticApplySortFunction(). This approach requires no #ifdef's and
should have the same effect as the existing source with GCC's view
of inline.
--
Dave Prosser [EMAIL PROTECTED] (908)790-2358 The SCO Group, Murray Hill, NJ
--
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] Request for supported platforms
On Mon, 2002-10-28 at 10:20, Jason Tishler wrote: 2. Cygwin bison limit exceeded: make[4]: Entering directory `/home/jt/src/pgsql/src/interfaces/ecpg/preproc' [snip] bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded I believe a new bison is required now. Don't know much about it other than ecpg hit some limit or other and much discussion followed. Iirc, it's only an issue when compiling from CVS, not a tarball. The above should help save me some time. 1.50 of Bison fixed the issue, 1.75 works as well (current public release). Just my $.02. Thanks, Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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] [ANNOUNCE] Server downtime ...
On Mon, 2002-10-28 at 11:33, Marc G. Fournier wrote: Ummm .. by the fact that you see [ANNOUNCE] in the above subject, I did send it to -announce :) I think he was saying that this was **NOT** stuff he wants to see on -ANNOUNCE. 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] Request for supported platforms
On Mon, 2002-10-28 at 14:58, Dave Page wrote: My WAG is that you will be able to upgrade your Cygwin installation before I fix the Cygwin build issues. :,) I guess my WAG was wrong... :,) I've been meaning to ask this for a while - what exactly is a WAG? :-) Wild-A**ed-Guess, I would presume. -- 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] FreeBSD 4.7: BETA3 (from port): regression failures...
On Mon, 2002-10-28 at 00:20, Larry Rosenman wrote: On Mon, 2002-10-28 at 00:09, Larry Rosenman wrote: Ignore the first one, stupid me forgot about permissions. Here is the real one (horology and geometry): (and I expect horology is due to DST change day). The geometry on FreeBSD4.7 MATCHES EXACTLY geometry-bsdi-precision.out. $ diff -c ../expected/geometry-bsdi-precision.out geometry.out $ So, how can we change the resultmap to take the 4.7 stuff into account? LER *** ./expected/geometry-positive-zeros-bsd.outTue Sep 12 16:07:16 2000 --- ./results/geometry.outMon Oct 28 00:15:32 2002 *** *** 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) --- 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) *** *** 224,233 twentyfour | rotation +- | (0,0),(0,0) ! | (0,0),(-20,-20) ! | (0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) --- 224,233 twentyfour | rotation +- | (0,0),(0,0) ! | (-0,0),(-20,-20) ! | (-0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,-0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) *** *** 254,264 WHERE (p.f1 - point '(0,0)') = 1; twenty | rotation +--- ! | (0,0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) --- 254,264 WHERE (p.f1 - point '(0,0)') = 1; twenty | rotation +--- ! | (0,-0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,-0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) *** *** 266,272 | (0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825) | (0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521) | (0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825) ! | (0,0.0828402366863905),(-0.201183431952663,0) | (-0.100591715976331,0.124260355029586),(-0.301775147928994,0.0414201183431953) | (-0.251479289940828,0.103550295857988),(-0.322485207100592,0.0739644970414201) | (-0.301775147928994,0.124260355029586),(-0.301775147928994,0.124260355029586) --- 266,272 | (0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825) | (0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521) | (0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825) ! | (-0,0.0828402366863905),(-0.201183431952663,0) | (-0.100591715976331,0.124260355029586),(-0.301775147928994,0.0414201183431953) | (-0.251479289940828,0.103550295857988),(-0.322485207100592,0.0739644970414201) | (-0.301775147928994,0.124260355029586),(-0.301775147928994,0.124260355029586) == *** ./expected/horology.out Wed Sep 18 16:35:25 2002 --- ./results/horology.outMon Oct 28 00:15:33 2002 *** *** 537,549 SELECT (timestamp
Re: [HACKERS] FreeBSD 4.7: BETA3 (from port): regression failures...
On Mon, 2002-10-28 at 21:33, Bruce Momjian wrote: See the resultmap file in the regression directory. I see: geometry/.*-bsdi=geometry-bsdi-precision geometry/.*-darwin=geometry-powerpc-darwin geometry/i.86-.*-freebsd=geometry-positive-zeros-bsd geometry/alpha.*-freebsd=geometry-positive-zeros geometry/i.86-.*-openbsd=geometry-positive-zeros-bsd geometry/sparc-.*-openbsd=geometry-positive-zeros geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros geometry/.*-sysv5.*:cc=geometry-uw7-cc geometry/.*-sysv5.*:gcc=geometry-uw7-gcc I assume we need to modify the FreeBSD entries. Once you give me a string to match your OS, I will rename geometry-bsdi-precision to something non-OS specific. I assume we need a string that is 4.7-only. geometry/i.86-.*-freebsd4.7= I think... I don't see where it picks out the release? LER --- Larry Rosenman wrote: On Mon, 2002-10-28 at 00:20, Larry Rosenman wrote: On Mon, 2002-10-28 at 00:09, Larry Rosenman wrote: Ignore the first one, stupid me forgot about permissions. Here is the real one (horology and geometry): (and I expect horology is due to DST change day). The geometry on FreeBSD4.7 MATCHES EXACTLY geometry-bsdi-precision.out. $ diff -c ../expected/geometry-bsdi-precision.out geometry.out $ So, how can we change the resultmap to take the 4.7 stuff into account? LER *** ./expected/geometry-positive-zeros-bsd.outTue Sep 12 16:07:16 2000 --- ./results/geometry.outMon Oct 28 00:15:32 2002 *** *** 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) --- 114,120 | (5.1,34.5) | [(1,2),(3,4)] | (3,4) | (-5,-12) | [(1,2),(3,4)] | (1,2) | (10,10)| [(1,2),(3,4)] | (3,4) ! | (0,0) | [(0,0),(6,6)] | (-0,0) | (-10,0)| [(0,0),(6,6)] | (0,0) | (-3,4) | [(0,0),(6,6)] | (0.5,0.5) | (5.1,34.5) | [(0,0),(6,6)] | (6,6) *** *** 224,233 twentyfour | rotation +- | (0,0),(0,0) ! | (0,0),(-20,-20) ! | (0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) --- 224,233 twentyfour | rotation +- | (0,0),(0,0) ! | (-0,0),(-20,-20) ! | (-0,2),(-14,0) | (0,79.2),(-58.8,0) ! | (14,-0),(0,-34) | (0,40),(0,0) | (0,0),(0,0) | (-10,-10),(-30,-30) *** *** 254,264 WHERE (p.f1 - point '(0,0)') = 1; twenty | rotation +--- ! | (0,0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) --- 254,264 WHERE (p.f1 - point '(0,0)') = 1; twenty | rotation +--- ! | (0,-0),(-0.2,-0.2) | (-0.1,-0.1),(-0.3,-0.3) | (-0.25,-0.25),(-0.25,-0.35) | (-0.3,-0.3),(-0.3,-0.3) ! | (0.08,-0),(0,-0.56) | (0.12,-0.28),(0.04,-0.84) | (0.26,-0.7),(0.1,-0.82) | (0.12,-0.84),(0.12,-0.84) *** *** 266,272 | (0.0976764836465887,-0.0241724631246608),(0.0325588278821962,-0.0725173893739825) | (0.109762715208919,-0.0562379754328844),(0.0813970697054906,-0.0604311578116521) | (0.0976764836465887,-0.0725173893739825),(0.0976764836465887,-0.0725173893739825
Re: [HACKERS] FreeBSD 4.7: BETA3 (from port): regression failures...
On Mon, 2002-10-28 at 21:45, Bruce Momjian wrote: Larry Rosenman wrote: On Mon, 2002-10-28 at 21:33, Bruce Momjian wrote: See the resultmap file in the regression directory. I see: geometry/.*-bsdi=geometry-bsdi-precision geometry/.*-darwin=geometry-powerpc-darwin geometry/i.86-.*-freebsd=geometry-positive-zeros-bsd geometry/alpha.*-freebsd=geometry-positive-zeros geometry/i.86-.*-openbsd=geometry-positive-zeros-bsd geometry/sparc-.*-openbsd=geometry-positive-zeros geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros geometry/.*-sysv5.*:cc=geometry-uw7-cc geometry/.*-sysv5.*:gcc=geometry-uw7-gcc I assume we need to modify the FreeBSD entries. Once you give me a string to match your OS, I will rename geometry-bsdi-precision to something non-OS specific. I assume we need a string that is 4.7-only. geometry/i.86-.*-freebsd4.7= I think... I don't see where it picks out the release? resultmap is read by pg_regress.sh. I made the following addition: geometry/i.86-.*-freebsd4.7=geometry-bsdi-precision (The anon cvs server hasn't updated yet), and we pass geometry. Still fail horology, but I suspect that's DST change day fubar. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] good news: FreeBSD 4.7: all passed (with Bruce's resultmap change).
With Bruce's resultmap change, and now that we are beyond the DST stuff: == All 89 tests passed. == lerlaptop# uname -a FreeBSD lerlaptop.lerctr.org 4.7-STABLE FreeBSD 4.7-STABLE #13: Fri Oct 25 01:32:16 CDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LERLAPTOP i386 lerlaptop# -- 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://archives.postgresql.org
Re: [HACKERS] 7.3b3 ok on unixware 71[12] here
On Wed, 2002-10-30 at 12:08, Olivier PRENANT wrote: I'm glad to tell that I compiled and run regression tests ok on unixware 711 and 712 (Openunix 800) as well as on mac OS X 10.2.1 (execpt for float8) However, I'm still struggling to make plperl work on perl 561 and Unixware. I've scanned te Web and every thing without comming to a clue of what to do. It DID work on pg 723 though... I've got it running with 5.8.0 of Perl. Is there anything holding you back from updating to 5.8.0 of PERL? 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) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Request for supported platforms
On Fri, 2002-11-01 at 01:57, Sean Chittenden wrote: Seems like someone ought to issue a call for port reports. The supported platforms list hasn't been touched ... Good point. Thomas, can you take that on? No, at least not now. I'm not able to communicate reliably with the mailing lists, and so can not coordinate anything :( Not sure when or if that will be resolved, but I'll be out of town next week so... [ Reposted with proper subject line.] OK, Tom will be away next week, and Thomas will too. I can do it. Folks. start sending in those plaform reports, OS name and version number please. The current platform list is: http://developer.postgresql.org/docs/postgres/supported-platforms.html $ uname -a FreeBSD avienda.nxad.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Mon Oct 28 18:20:14 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DELLAPTOP i386 $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) Looks like the only problem on beta3 is that the geometry bits are failing, but I'm not 100% if they haven't already been solved. -sc Can you check it against the geometry-bsd[i]-precision.out file? (depending on whether you've updated since the weekend). If it matches, we need to update the resultmap. 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] Request for supported platforms
On Fri, 2002-11-01 at 09:53, Tom Lane wrote: Sean Chittenden [EMAIL PROTECTED] writes: $ uname -a FreeBSD avienda.nxad.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Mon Oct 28 18:20:14 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DELLAPTOP i386 Looks like the only problem on beta3 is that the geometry bits are failing, but I'm not 100% if they haven't already been solved. -sc Hmm. Evidently you now have support for minus-zero. It looks like we have an updated comparison file for that case for FreeBSD, but it's only being applied for FreeBSD 4.7: geometry/i.86-.*-freebsd4.7=geometry-bsd-precision geometry/i.86-.*-freebsd=geometry-positive-zeros-bsd geometry/alpha.*-freebsd=geometry-positive-zeros Or at least it's *trying* to apply it for 4.7 --- as near as I can tell without testing, the above scrap of resultmap code is wrong because both of the i.86 lines will match on FreeBSD 4.7, and I think the pg_regress coding will take the last match. Larry, did you actually test the CVS-tip resultmap to make sure it picks the right comparison file on your box? Yes, just did and it *FAILS*. you need the order you have below. Sorry... We could possibly do geometry/i.86-.*-freebsd=geometry-positive-zeros-bsd geometry/i.86-.*-freebsd4.7=geometry-bsd-precision geometry/i.86-.*-freebsd5=geometry-bsd-precision geometry/alpha.*-freebsd=geometry-positive-zeros which is mighty ugly, but I'm hopeful that by the next PG release we'll have gotten rid of most of the platform-to-platform geometry variants anyway. 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 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 7.3B3 psql talking to a 7.2.3 server?
Is the following supposed to work? $ psql -U neteng -h tide netmaster ERROR: parser: parse error at or near . Welcome to psql 7.3b3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit netmaster= select version(); version - PostgreSQL 7.2.1 on i386-portbld-freebsd4.5, compiled by GCC 2.95.3 (1 row) netmaster= neteng **IS** a superuser on tide. -- 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] 7.3B3 psql talking to a 7.2.3 server?
On Fri, 2002-11-01 at 10:38, Rod Taylor wrote: On Fri, 2002-11-01 at 11:30, Larry Rosenman wrote: Is the following supposed to work? $ psql -U neteng -h tide netmaster ERROR: parser: parse error at or near . 7.3 psql is schema safe. So... it's trying to do silly things like: SELECT * FROM pg_catalog.pg_class; Of course, 7.2 and earlier did not support such syntax. I know this, the question is, Should this happen? If not, can we fix it somehow? Or do we need to put a note 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
