Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"
On 2016-02-10 16:19, Tom Lane wrote: I wrote: Artur Zakirov writes: I think this is not a bug. It is a normal behavior. In Mac OS sscanf() with the %s format reads the string one character at a time. The size of letter 'х' is 2. And sscanf() separate it into two wrong characters. That argument might be convincing if OSX behaved that way for all multibyte characters, but it doesn't seem to be doing that. Why is only 'х' affected? I looked into the OS X sources, and found that indeed you are right: *scanf processes the input a byte at a time, and applies isspace() to each byte separately, even when the locale is such that that's a clearly insane thing to do. Since this code was derived from FreeBSD, FreeBSD has or once had the same issue. (A look at the freebsd project on github says it still does, assuming that's the authoritative repo.) Not sure about other BSDen. I also verified that in UTF8-based locales, isspace() thinks that 0x85 and 0xA0, and no other high-bit-set values, are spaces. Not sure exactly why it thinks that, but that explains why 'х' fails when adjacent code points don't. So apparently the coding rule we have to adopt is "don't use *scanf() on data that might contain multibyte characters". (There might be corner cases where it'd work all right for conversion specifiers other than %s, but probably you might as well just use strtol and friends in such cases.) Ugh. regards, tom lane Definitive FreeBSD Sources: https://svnweb.freebsd.org/base/ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"
On 2016-02-10 17:00, Tom Lane wrote: Larry Rosenman writes: On 2016-02-10 16:19, Tom Lane wrote: I looked into the OS X sources, and found that indeed you are right: *scanf processes the input a byte at a time, and applies isspace() to each byte separately, even when the locale is such that that's a clearly insane thing to do. Since this code was derived from FreeBSD, FreeBSD has or once had the same issue. (A look at the freebsd project on github says it still does, assuming that's the authoritative repo.) Not sure about other BSDen. Definitive FreeBSD Sources: https://svnweb.freebsd.org/base/ Ah, thanks for the link. I'm not totally sure which branch is most current, but at least on this one, it's still clearly wrong: https://svnweb.freebsd.org/base/stable/10/lib/libc/stdio/vfscanf.c?revision=291336&view=markup convert_string(), which handles %s, applies isspace() to individual bytes regardless of locale. convert_wstring(), which handles %ls, does it more intelligently ... but as I said upthread, relying on %ls would just give us a different set of portability problems. It looks like Artur's patch is indeed what we need to do, along with looking around for other *scanf() uses that are vulnerable. regards, tom lane that would be the current 10.x tree, production, and getting ready for 10.3 which is in code slush. If you want, file a bug at https://bugs.freebsd.org/bugzilla -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Renaming some binaries
On 2016-08-26 15:03, Andres Freund wrote: On 2016-08-26 22:01:58 +0200, Simon Riggs wrote: On 26 August 2016 at 18:26, Euler Taveira wrote: > I'm bringing this $subject into discussion again. Historically, we are > carrying binary names that have been confused newbies. createuser is the > worst name so for. Also, names like createdb, initdb, reindexdb, and > droplang does not suggest what product it is referring to. Adding a > prefix (pg_, pg, ...) would 'make things clear'. If we have a consensus > about this change, I suggest renaming the following binaries: > > clusterdb > createdb > createlang > createuser > dropdb > droplang > dropuser > initdb > oid2name > reindexdb > vacuumdb > vacuumlo Why not just remove them all and change the docs to suggest using psql -c "CREATE DATABASE foo" etc Less code, no confusion because we have just one client tool - psql. Several of them have the ability to connect to several databases, some even do that in parallel. vacuumdb being one that I've needed recently to do a number of DB's in a row. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FW: PGBuildfarm member peripatus Branch REL9_2_STABLE Failed at Stage PLCheck-C
Looks like the upgrade of this machine to the inode64 commit of FreeBSD busted stuff. I’m rebuilding perl and all the ports to see if that fixes it. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 On 5/23/17, 1:26 PM, "buildfarm-adm...@postgresql.org" wrote: The PGBuildfarm member peripatus had the following event on branch REL9_2_STABLE: Failed at Stage: PLCheck-C The snapshot timestamp for the build is: 2017-05-23 18:20:01 The specs of this machine are: OS: FreeBSD / HEAD Arch: X86_64 Comp: clang / 4.0.0 For more information, see https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=peripatus&br=REL9_2_STABLE -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FW: PGBuildfarm member peripatus Branch REL9_2_STABLE Status changed from PLCheck-C failure to OK
Rebuilding Perl and all it’s related ports fixed it. Dealing with the FreeBSD folks on what all we (FreeBSD) need to put in /usr/ports/UPDATING and / or /usr/src/UPDATING -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 On 5/23/17, 4:32 PM, "buildfarm-adm...@postgresql.org" wrote: The PGBuildfarm member peripatus had the following event on branch REL9_2_STABLE: Status changed from PLCheck-C failure to OK The snapshot timestamp for the build is: 2017-05-23 21:27:41 The specs of this machine are: OS: FreeBSD / HEAD Arch: X86_64 Comp: clang / 4.0.0 For more information, see https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=peripatus&br=REL9_2_STABLE -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] pg_upgrade: support for btrfs copy-on-write clones
On 2013-10-02 17:32, Josh Berkus wrote: No fundamental reason; I'm hoping ZFS will be supported in addition to btrfs, but I don't have any systems with ZFS filesystems at the moment so I haven't been able to test it or find out the mechanisms ZFS uses for cloning. On btrfs cloning is implemented with a custom btrfs-specific ioctl, ZFS probably has something similar which would be pretty easy to add on top of this patch. Would you like a VM with ZFS on it? I'm pretty sure I can supply one. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com I can also supply SSH access to a FreeBSD 10 system that is totally ZFS. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CLUSTER VERBOSE (9.1.3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any way to get more info out of CLUSTER VERBOSE so it says what index it's working on AFTER the table re-write? INFO: clustering "public.values" using sequential scan and sort INFO: "values": found 0 removable, 260953511 nonremovable row versions in 4224437 pages DETAIL: 0 dead row versions cannot be removed yet. CPU 168.02s/4324.68u sec elapsed 8379.12 sec. And at this point it's doing something(tm), I assume re-doing the indexes. It would be nice(tm) to get more info. Ideas? - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPVTLJAAoJENC8dtAvA1zmolAIAIgfqXTe5cWZ2ZGVXXVgzv3A pBhi1bVOEB8Xjcie82gMTyqBZKuTtIqNFHXWaB4xVxG6U93YGlru7DnUa8ArzbvW 31b0GHIeXpemUFz0OnuKv6h0Bt+H755YNuDXykN7a7VEdzwIrv/iSSGlBsbEywhG SdC1VvHrmUaRCfCV/XBF4tynC3rocRIyf29SJNPZJl9cJtkK2BDigUeHANN3mydQ 1H1WZ8CMfnTvi8vROGFuk5HCZDv0e9K9dYthfMEqIgKzBRu5jLagijADyEhVCJfO /JYP+t1eGPP1zYqf+R/OfMGTM0RYcP/XVRK8qS+8FPBTUPTphStjmOBPuHRYWDU= =GWPN -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CLUSTER VERBOSE (9.1.3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/6/2012 8:32 AM, Robert Haas wrote: > On Mon, Mar 5, 2012 at 4:40 PM, Larry Rosenman > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> Is there any way to get more info out of CLUSTER VERBOSE so it >> says what index it's working on AFTER the table re-write? >> >> INFO: clustering "public.values" using sequential scan and sort >> INFO: "values": found 0 removable, 260953511 nonremovable row >> versions in 4224437 pages DETAIL: 0 dead row versions cannot be >> removed yet. CPU 168.02s/4324.68u sec elapsed 8379.12 sec. >> >> >> And at this point it's doing something(tm), I assume re-doing the >> indexes. >> >> It would be nice(tm) to get more info. >> >> Ideas? > > Try setting client_min_messages=DEBUG1. At least on current > sources that gives some additional, relevant output; I think that's > probably there in 9.1.x as well. > Thanks. That helps some, but I'd like to see: 1) these moved up to INFO when CLUSTER VERBOSE 2) time/statistics on each index build INFO: clustering "public.values" using sequential scan and sort INFO: "values": found 0 removable, 260953511 nonremovable row versions in 4224437 pages DETAIL: 0 dead row versions cannot be removed yet. CPU 167.57s/4325.52u sec elapsed 7687.28 sec. DEBUG: building index "values_idx1" on table "values" DEBUG: building index "values_idx2" on table "values" DEBUG: building index "values_idx3" on table "values" DEBUG: building index "values_idx4" on table "values" DEBUG: building index "values_idx5" on table "values" DEBUG: building index "values_idx6" on table "values" DEBUG: building index "values_idx7" on table "values" DEBUG: building index "values_idx_cluster" on table "values" CLUSTER Time: 28997806.474 ms Comments? - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPV3GyAAoJENC8dtAvA1zmAzkIALJL/Ir7Ks3gYVy4bVB7Oamc Etpg6/hmM3+g0Ry9Lv3yUbaeHLxwuAaW+Gv5nDuepZFbMfAxYjsUG+fVUu8n3Xo3 V42/4TFxI7QQUtnwqkkMo0Y1vBNsmIRFuxx3b2R+ePKAZaQFLoElU7dL1JOA1u3c OQ0dUDtiUNTSa+ZrNYNbLhqOUUIooGrF8hWLKfmLOrbrRpAObrCeyaHW2qxRrIq/ wbvHG7YG1byRiDzZr4DNKrS4/88HXjgo2m8xmxyNf+1fKsa69fkIA+rbsqyEx4ui RAih9fQVQcjcK15XTyDchT21YRdwDZnjVt/Yh0IMvDE19sIQFfrs1QTGPnUULpI= =5bZG -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CLUSTER VERBOSE (9.1.3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/7/2012 12:31 PM, Alvaro Herrera wrote: > > Excerpts from Robert Haas's message of mié mar 07 11:57:41 -0300 > 2012: > >> Seems like a good enhancement to me, if someone can figure out >> how to do it cleanly. Unfortunately those debug messages may not >> be in a place where it's real easy for them to know whether >> they're being called from CLUSTER VERBOSE or not, so it might >> take a little thought to produce a clean patch for this. > > Another thing that occured to me in this general area was whether > it'd be useful to do something with ps_status and > pg_stat_activity. > > Also, this isn't limited to CLUSTER; anything that rewrites the > table and indexes would benefit. Meaning ALTER TABLE that does a > full rewrite, and also VACUUM FULL. > +1. I think we should update ps_status as well as pg_stat_activity as all of these table rewrite processes are running. Do I need to cogitate on the code, or is one of the hackers that knows it better interested? Thanks! - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPV64WAAoJENC8dtAvA1zmItsH/ib0uAh3Jqy6WKXrxBrJoy5k LBj/xfAs8Z3Xl0TQjoulgAgBV1NWo5DyKvvtmcxpEw1KkJZrpkWONB3I+Y3nQKiy rfD3uJ6tWvoD9Ay+InPy0W8qReTSKSSI09au60OzU8Ez3UX5JEGhiibn1B6AvXKy 5JWGRJF64fKEnDOresVHqGGhlLM3lelsS7nMX0rs8kZ20BG3tLPjqZslm/qZ3w9M OJJpJKOlZCoNs+YZTtNxGeRhKXWSfsao6tYc/8To7pbJ6m9MKyqcou7g8yJXZrJr +BFwPyRG+/p6Li0tWmsuD8FtuPFFp37HxeduKzJNN9sqA3TSeadN8kZweb8zak8= =jrEi -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CLUSTER VERBOSE (9.1.3)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/7/2012 2:42 PM, Tom Lane wrote: > Larry Rosenman writes: >> On 3/7/2012 12:31 PM, Alvaro Herrera wrote: >>> Also, this isn't limited to CLUSTER; anything that rewrites >>> the table and indexes would benefit. Meaning ALTER TABLE that >>> does a full rewrite, and also VACUUM FULL. > >> +1. I think we should update ps_status as well as >> pg_stat_activity as all of these table rewrite processes are >> running. > > -1. Updating ps_status is expensive, seriously so on some > platforms. We could likely get away with tracking progress in > pg_stat_activity though. > > However, this just reminds me that tracking intrastatement progress > in pg_stat_activity has been discussed before and not much has > happened. Let's please not have a quick kluge that just addresses > CLUSTER and not any of the other aspects of that problem. > > regards, tom lane > OOppss. I forgot that it's expensive on ps_status (I think my favorite platform, FreeBSD, is one of those :(). I do think that pg_stat_activity should be updated, as well as pushing more of the DEBUG1 progress messages up to INFO, and adding some sort of timing / statistical info on the create index commands that are run. Is any of the -hackers community interested, or should I try(!) to look at the code? - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPV8rRAAoJENC8dtAvA1zmt90IAL7M15RBl6k03Tq18ehUMdos SKSAT/dSPEaQJx55GIPNy+uE6miiNS8Vo493SJ007hsyob/fuxdhXMfWalrc/qdE BFsIBNiGJEsy0kyQxhXmXneQurgt1jbntGmCc/rSybd7aDq72fE81G6NaQGXqIOq FMl3MqQpQuOjL8cCfGgwpsV9paipmlcQTzc52aAcj1Yj15twFySx/P3N18oNX9NP 6JUEgEl6FLP0UQ31roxzbulLR0imoACAThaOOp1swxPREahjkltoU08wk/MeR6xv hR76is80/16I1hj6DLXwAl6C/Dmmt3ufrKTHKguXJU6RAJI11+05MbSiBIO5wCI= =rWW2 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New email address
On 2015-11-24 13:11, Tom Lane wrote: Kevin Grittner writes: On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane wrote: change the From header (and add a Reply-To, so replies still work). If this were done, would the other steps (not changing the subject or body of the email) be necessary? See my followup: I think it's probably true that we could skip those changes. But Rudy commented that there's a lot of underdocumented subtlety here. There might be reasons I'm missing why we'd need to stop doing those things. It doesn't seem like DMARC as such would force that, but perhaps those things trigger some popular antispam heuristics. regards, tom lane Any Header or Body changes will invalidate most, if not all, DKIM signatures. Since DKIM is used as part of DMARC, it's a problem. Not sure what MajorDomo2 will allow you to do. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New email address
On 2015-11-24 13:43, Alvaro Herrera wrote: Larry Rosenman wrote: On 2015-11-24 13:11, Tom Lane wrote: >Kevin Grittner writes: >>On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane wrote: >>>>change the From header (and add a Reply-To, so replies still work). > >>If this were done, would the other steps (not changing the subject >>or body of the email) be necessary? > >See my followup: I think it's probably true that we could skip those >changes. But Rudy commented that there's a lot of underdocumented >subtlety here. There might be reasons I'm missing why we'd need to >stop doing those things. It doesn't seem like DMARC as such would >force that, but perhaps those things trigger some popular antispam >heuristics. Any Header or Body changes will invalidate most, if not all, DKIM signatures. Since DKIM is used as part of DMARC, it's a problem. Not sure what MajorDomo2 will allow you to do. We can turn off header and body changes easily enough, but changing the "From:" address requires patching the Majordomo2 source code; and, as you may already be aware, the maintainers gave up on Mj2 a decade ago, so we'd be on our own for that. I cannot promise any sort of timeline for getting that done; and since that's an essential part of the recipe, I don't see any point in doing the other changes either for the time being. I think the breakage of DKIM signatures is already causing some pain (though nowhere near the level of DMARC). Of course, removing all the "List-" headers *and* our custom footers is a huge step backwards in terms of mailing list functionality :-( Also, removing the [HACKERS] etc tags will annoy some people, for sure. You don't have to remove the List- headers. DKIM says what headers it's using. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 10.0
On 2016-05-13 10:34, Thom Brown wrote: On 13 May 2016 at 16:29, Dave Page wrote: On Fri, May 13, 2016 at 4:23 PM, Thom Brown wrote: Well, one potential issues is that there may be projects which have already coded in 9.6 checks for feature support. I suspect that won't be an issue (I never heard of it being for 7.5, which was released as 8.0 - but is smattered all over pgAdmin 3 for example) - largely because in such apps we're almost always checking for a version greater than or less than x.y. I imagine the bigger issue will be apps that have been written assuming the first part of the version number is only a single digit. Is that likely? That would be remarkably myopic, but I guess possible. Thom We (FreeBSD) had lots of that kind of fallout when 9->10. Autoconf, and other tools thought we were a.out and not ELF. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] What X86/X64 OS's do we need coverage for?
I'm in the process of building a new box that will have Dual Xeon 5120's (Dual Core), and 4G of ram and 2.4T of disk (6x400G SATA). It will have CentOS 4.4 X86_64 as the base os with VMWare Server running on it. I am willing to run any X86 or X64 OS's in VM's as buildfarm clients. What OS's do we need coverage for? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
I might use that as the base then, since the hardware finishes getting here tomorrow. My question still stands on what OS's we need coverage for. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua D. Drake Sent: Thursday, April 05, 2007 6:18 PM To: Larry Rosenman Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] What X86/X64 OS's do we need coverage for? > > It will have CentOS 4.4 X86_64 as the base os with VMWare Server running > on it. > > > > I am willing to run any X86 or X64 OS's in VM's as buildfarm clients. > > > > What OS's do we need coverage for? CentOS5 hits ina couple days. J > > > > LER > > > > > > -- > > Larry Rosenman http://www.lerctr.org/~ler > > Phone: +1 512-248-2683 E-Mail: ler@lerctr.org > > US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 > > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
On Fri, 6 Apr 2007, Matthew O'Connor wrote: Devrim G??nd??z wrote: Hi, On Fri, 2007-04-06 at 01:23 -0400, Matthew T. O'Connor wrote: The other thing to consider is that CentOS 5 has Xen built right in, so you should be able run VMs without VMWare on it. ... if the kernel of the OS has Xen support, there will be no performance penalty (only 2%-3%) (Para-virtualization). Otherwise, there will be full-virtualization, and we should expect a performance loss about 30% for each guest OS (like Windows). I may be wrong but I thought that the guest OS kernel only needs special support if the underlying CPU doesn't have virtualization support which pretty much all the new Intel and AMD chips have. No? It doesn't matter as far as MY box is concerned. I use VMWare extensively in my current $DAYJOB, and I want to be able to test/play with things related to that as well. The box I'm building will be using the (free) VMWare Server as it's virtualization platform. I'd still like to hear from a Tom Lane or someone else on the project with what X86 or X86_64 OS's we need coverage for. LER ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
On Fri, 6 Apr 2007, Andrew Dunstan wrote: Larry Rosenman wrote: It doesn't matter as far as MY box is concerned. I use VMWare extensively in my current $DAYJOB, and I want to be able to test/play with things related to that as well. The box I'm building will be using the (free) VMWare Server as it's virtualization platform. I'd still like to hear from a Tom Lane or someone else on the project with what X86 or X86_64 OS's we need coverage for. VMWare Server is indeed a fine product, which I use extensively. I am not sure what our Windows support is like for x86_64. Magnus has one for MSVC (for which buildfarm support is nearly done, but not quite). But I don't see one for MinGW. OTOH, Windows is not free (in either sense) and setting up a build environment there is quite a bit harder than on Unix platforms. If someone wants to supply the appropriate licenses, I would be willing to run windows VM's on this beast. I don't have the free cash to pony up the licenses. The other platform I've whined about missing for some time is HP-UX, especially on PA-RISC. But that's a whole different story. I'm seeing if I can use some HP-UX boxes I have at the office to supply HP-UX 11.11 PA-800's. No guarantees at this point, but I am asking. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
On Fri, 6 Apr 2007, Stefan Kaltenbrunner wrote: Andrew Dunstan wrote: Larry Rosenman wrote: It doesn't matter as far as MY box is concerned. I use VMWare extensively in my current $DAYJOB, and I want to be able to test/play with things related to that as well. The box I'm building will be using the (free) VMWare Server as it's virtualization platform. I'd still like to hear from a Tom Lane or someone else on the project with what X86 or X86_64 OS's we need coverage for. VMWare Server is indeed a fine product, which I use extensively. I am not sure what our Windows support is like for x86_64. Magnus has one for MSVC (for which buildfarm support is nearly done, but not quite). But I don't see one for MinGW. OTOH, Windows is not free (in either sense) and setting up a build environment there is quite a bit harder than on Unix platforms. yeah improving windows coverage might be a nice thing - some other random thoughts might include: *) a linux x86_64 box with say the non-commercial version of icc (intel c compiler) *) recent netbsd/amd64 *) solaris 10/x86 - gcc and sun studio *) maybe solaris express/opensolaris? *) as said early we don't seem to have any suse/novell coverage at all I'll see what I can do on the NetBSD and Solaris fronts. though generally the x86/x64_86 coverage seems to be quite good The other platform I've whined about missing for some time is HP-UX, especially on PA-RISC. But that's a whole different story. there are more obscure and rare platforms(both in terms that might be a win for the buildfarm but HP-UX is really missing. Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
On Sat, 7 Apr 2007, Josh Berkus wrote: Folks, I'll see what I can do on the NetBSD and Solaris fronts. IMO, the Solaris one is probably more important than NetBSD. Solaris is taken care of ... should be online in a week or two. Sun DBTG Q.A. set up in the Sun labs: Solaris 9 + Sparc + SunCC Solaris 8 + Sparc + SunCC Solaris 10 + Sparc + SunCC Solaris 10 + x86 + SunCC Solaris 10 + x86 + gcc Solaris Nevada + Sparc + SunCC Solaris Nevada + x86 + SunCC Solaris Nevada + x86 + gcc ... which ought to cover most of the platforms we're interested in from Solaris. The 8 and 9 machines will just build current, but the 10 and Nevada machines will build CVS, 8.1, 8.2 and rotationally older versions (once each week). We're building in as many options as we have support for, including perl, kerberos (on Nevada), Dtrace (on 8.2) and integer-datetimes. Given Sun handling Solaris, my question is: 1) what os(s) do we need more coverage on 2) what collection of options for OS' in 1? LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
On Mon, 9 Apr 2007, Adrian Maier wrote: > The other platform I've whined about missing for some time is HP-UX, > especially on PA-RISC. But that's a whole different story. there are more obscure and rare platforms(both in terms that might be a win for the buildfarm but HP-UX is really missing. Hello, I have access to a PA-RISC machine running HP-UX 11.11. Unfortunately the machine is on a dedicated network and has no Internet access. It should be possible to create a mirror of the CVS repository on my machine (which has access to both the Internet and the dedicated network) so that the HP-UX server could get the sources from my machine. But I am not sure whether the results could be reported back to the buildfarm. I think I'll be able to set up my HP-UX 11.11 box here, as soon as it gets fixed, and assuming either the bundled compiler will work or I can get GCC on it. This will take a week or 2, but I have permission now. (This box can get out to the internet via our proxy). LER Cheers, Adrian Maier -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] What X86/X64 OS's do we need coverage for?
On Mon, 9 Apr 2007, Tom Lane wrote:
Larry Rosenman writes:
I think I'll be able to set up my HP-UX 11.11 box here, as soon as it gets
fixed, and assuming either the bundled compiler will work or I can get
GCC on it.
If the bundled compiler is still the same non-ANSI-C weakling that was
bundled in HPUX 10, there's no chance. It would be great to have a
buildfarm member using HP's real ANSI-spec C compiler though.
I still do a lot of my own development on HPUX 10 + gcc, so I'm not
particularly worried about lack of that combination in the buildfarm.
Looks like we are a DSPP member, so I might be able to get the aCC bundle
for free, and if so, I'll set it up with that.
Thanks,
LER
regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
[HACKERS] CREATE DATABASE foo OWNER bar
Greetings, I think I found a bug, or at least a POLA violation. At work, I created a user that is NOT a superuser, nor can that user create databases. When I did a create database foo owner bar, all the schemas are set to be owned by the superuser that created the database, not the database owner. Shouldn't everything that is in the DB be owned by the purported owner? This is on 8.2.3, btw. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CREATE DATABASE foo OWNER bar
On Mon, 16 Apr 2007, Andrew Dunstan wrote: Larry Rosenman wrote: Greetings, I think I found a bug, or at least a POLA violation. At work, I created a user that is NOT a superuser, nor can that user create databases. When I did a create database foo owner bar, all the schemas are set to be owned by the superuser that created the database, not the database owner. Shouldn't everything that is in the DB be owned by the purported owner? This is on 8.2.3, btw. Thanks! umm ... objects are initially owned by their creator, no? Ownership of a db means you can grant privs over the db, but ownership doesn't cascade. If you want your user to own objects you should arrange for that user to create them, or run ALTER objtype foo OWNER TO username. The latter is what pg_dump does. the issue is the initial schemas like PUBLIC. When I try and RESTORE a pg_dump in the current state, we get errors because the public schema is owned by postgres, and the grant commands are issued as the user (since I'm restoring as the purported owner. It would seem to me, that the CREATE DATABASE command should change the owner of them to the OWNER verb. $ psql postgres Welcome to psql 8.2.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit postgres=# \du test List of roles Role name | Superuser | Create role | Create DB | Connections | Member of ---+---+-+---+-+--- test | no| no | no| no limit| (1 row) postgres=# create database testing owner test; CREATE DATABASE postgres=# \c test You are now connected to database "test". test=# \dn List of schemas Name| Owner +--- information_schema | pgsql pg_catalog | pgsql pg_toast | pgsql public | pgsql (4 rows) test=# I would have expected these to be owned by test... cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] CREATE DATABASE foo OWNER bar
On Mon, 16 Apr 2007, Tom Lane wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
When I try and RESTORE a pg_dump in the current state, we get errors because
the public schema is owned by postgres, and the grant commands are issued
as the user (since I'm restoring as the purported owner.
That's a different issue entirely, which is that if you want to restore
a dump containing objects of multiple ownerships, you need to be
superuser; else you can't "give away" the ownership.
I guess the issue is that I'd expect public to be owned by the DB Owner after
a CREATE DATABASE foo OWNER bar, which would then quiet up the pg_restore
since that is the error we get on the public schema.
I've remedy'ed the issue with a ALTER SCHEMA, but I think PG ought to do that.
LER
regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED]
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[HACKERS] Makefile support for Mac OS X Fat Binaries?
would the community accept a patch that would allow the making of 4-way fat binaries on Mac OS X 10.5+? (Obviously for 8.4+). I'm thinking about attempting it for an inside project here at work, but was wondering if there was community interest? Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Makefile support for Mac OS X Fat Binaries?
On Mon, 21 Jan 2008, Tom Lane wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
would the community accept a patch that would allow the making of 4-way fat
binaries on Mac OS X 10.5+? (Obviously for 8.4+).
Depends on how big and ugly it is, I think. If you can do it just by
hacking CFLAGS and friends, sure; if it's as invasive as the Windows
build machinery, definitely not; in between, we'd have to see it.
I know I'm going to have to make a few lipo runs, and shell for-loops
to make the different SUBSYS.o's. (ld by itself won't do it).
I'll see how grotty it is, but I don't think it will be nearly as bad as the
Windows machinery.
regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED]
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Makefile support for Mac OS X Fat Binaries?
On Tue, 22 Jan 2008, Gregory Stark wrote: "Tom Lane" <[EMAIL PROTECTED]> writes: Larry Rosenman <[EMAIL PROTECTED]> writes: would the community accept a patch that would allow the making of 4-way fat binaries on Mac OS X 10.5+? (Obviously for 8.4+). Depends on how big and ugly it is, I think. If you can do it just by hacking CFLAGS and friends, sure; if it's as invasive as the Windows build machinery, definitely not; in between, we'd have to see it. We've been through this once already. You can't do it (cleanly) with just Makefile hackery. The architectures have different endianness and possibly other ABI differences. To handle that cleanly you have to run configure once for each architecture and build each architecture with the appropriate config.h. Could we then combine the executables into one 4-way fat binary ? I'll see what I come up with. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Sought after architectures for the PostgreSQL buildfarm?
I might be able to help with: Sparc PA-Risc (HP-UX) IA64 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -Original Message- From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Josh Berkus Sent: Tuesday, December 08, 2009 11:43 AM To: Andrew Dunstan Cc: PostgreSQL-development; Peter St. Onge Subject: Re: [HACKERS] Sought after architectures for the PostgreSQL buildfarm? On 12/8/09 7:51 AM, Andrew Dunstan wrote: > > > Peter St. Onge wrote privately: >> >> With the local server room renovations, there may be some older >> equipment being retired. Are there any architectures that you would >> like to see added to the buildfarm? Got any Sparc machines? We're likely about to lose our sparc buildfarm. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 vs. 9.0
On Thu, January 21, 2010 5:53 pm, Andreas Joseph Krogh wrote: > On Thursday 21. January 2010 10.37.41 Dave Page wrote: >> In an attempt to pre-empt the normally drawn-out discussions about >> what the next version of PostgreSQL will be numbered. the core team >> have discussed the issue and following a lenghty debate lasting >> literally a few minutes decided that the next release shall be >> >> Wait for it >> >> 9.0. > > Care to shed some light on what features (yes, we users care about > features) warrant this major version-bump? Is there a link somewhere? AFAIR, it was stated if Hot Standby AND Streaming Replication hit the tree, the release number would go to 9.0. Both are in the tree. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Rules: A Modest Proposal
On Sun, October 4, 2009 1:48 pm, Pavel Stehule wrote: > 2009/10/4 David Fetter : >> Folks, >> >> At the moment, user-accessible RULEs have, as far as I know, just two >> sane uses: >> >> * Writing to VIEWs >> * Routing writes to partitions > > somebody use it as instead triggers. And I am sure, so there are > people, who use it for writable views. We have such a rule (instead of a trigger) in our SaaS app. I'm lobbying to remove it, and make it a real trigger, but that hasn't happened yet. so there are folks out there. > > regards > Pavel Stehule > >> >> And the second is pretty thin, given the performance issues for >> numbers of partitions over 2. >> >> What say we see about addressing those problems separately, and >> removing user-accessible RULEs entirely? >> >> There are already patches to deal with the first, at least for the >> kinds of VIEWs where this can be deduced automatically, and people are >> starting to take on the second. >> >> The one remaining (as in nobody's really addressed it with code) issue >> would be triggers on VIEWs.  As other systems have done it, it's >> clearly not essentially impossible.  What would be needed? >> >> Cheers, >> David. >> -- >> David Fetter http://fetter.org/ >> Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter >> Skype: davidfetter    XMPP: david.fet...@gmail.com >> >> Remember to vote! >> Consider donating to Postgres: http://www.postgresql.org/about/donate >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers >> > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Fix for large file support (nonsegment mode support)
On Mon, 10 Mar 2008, Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Tom Lane wrote: Applied with minor corrections. Why is this not the default when supported? Fear. Maybe eventually, but right now I think it's too risky. One point that I already found out the hard way is that sizeof(off_t) = 8 does not guarantee the availability of largefile support; there can also be filesystem-level constraints, and perhaps other things we know not of at this point. Just to note an additional filesystem that will need special action... The VxFS filesystem has a largefiles option, per filesystem. At least that was the case on SCO UnixWare (No, I no longer run it). LER regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: [EMAIL PROTECTED] US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Use of /etc/services?
On Fri, 2002-06-07 at 10:55, Michael Alan Dorman wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Peter Eisentraut wrote: > > > Since we now have an official entry in /etc/services, shouldn't we be able > > > to make use of it, by using getservbyname() if a nonnumeric port number is > > > specified? > > Is any OS actually shipping us in /etc/services? > > Debian GNU/Linux is, or at least will be for the imminent 3.0 release. It's in FreeBSD 4-STABLE, and definitely in 4.6-RELEASE which is due out tomorrow. (or shortly thereafter). > > Mike. > > ---(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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Feature request: Truncate table
On Wed, 2002-06-12 at 14:32, Dann Corbit wrote: > Deletion of data from a PostgreSQL table is very slow. > > It would be nice to have a very fast delete like "truncate table." > > Now, truncate is a very dangerous command because it is not logged (but > the same is true for other operations like bulk copy and select into). > So one needs to be careful how this command is granted. The same damage > (accidental deletion of all data) can be done by drop table just as > easily. > > I frequently have to do this right now in PostgreSQL, but I simply > emulate it by drop table/create table. It's there: $ psql Welcome to psql, 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 ler=# select version(); version - PostgreSQL 7.2.1 on i386-portbld-freebsd4.6, compiled by GCC 2.95.3 (1 row) ler=# \h truncate Command: TRUNCATE Description: empty a table Syntax: TRUNCATE [ TABLE ] name ler=# > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature request: Truncate table
On Wed, 2002-06-12 at 13:37, Billy O'Connor wrote: >Deletion of data from a PostgreSQL table is very slow. > >It would be nice to have a very fast delete like "truncate table." > >Now, truncate is a very dangerous command because it is not logged (but >the same is true for other operations like bulk copy and select into). >So one needs to be careful how this command is granted. The same damage >(accidental deletion of all data) can be done by drop table just as >easily. > >I frequently have to do this right now in PostgreSQL, but I simply >emulate it by drop table/create table. > > What is a TRUNCATE TABLE but a drop create anyway? Is there some > technical difference? > It doesn't kill indexes/triggers/constraints/Foreign Key Stuff, etc. -- 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] Integrating libpqxx
On Wed, 2002-06-12 at 17:30, Bruce Momjian wrote: > Jeroen T. Vermeulen wrote: > > On Wed, Jun 12, 2002 at 05:48:46PM -0400, Bruce Momjian wrote: > > > > > > I can add it to CVS as interfaces/libpqxx and we can then let others > > > merge your configure tests into our main configure. Let me know when > > > you want it dumped into CVS. > > > > Might as well do it right now, with 0.5.2. We'll call that 1.0, and > > leave the more radical future plans for 2.0. > > > > There are some things I'd like to do in future 1.x releases that will > > affect the interface: > > - nonblocking operation, probably as a latency-hiding tuple stream; > > - change the way you select the quality of service for your transactor; > > - allow notice processors to have C++ linkage; > > - addtional bits & bobs like field and column iterators. > > > > OTOH there's no point in delaying 1.0 forever I guess. > > > > FWIW, I'm thinking of doing at least one of the following in 2.0: > > - an easy-to-use but intrusive object persistence layer; > > - offload some of the work to BOOST if possible; > > - adapt the interface to be more database-portable. > > > > But back to 1.0... Would it be a useful idea to also integrate my own > > CVS history into the main tree? Or should I just keep developing in > > my local tree and submit from there? > > I think we will just give you CVS access. Not sure how to get the CVS > history. I think if you send me the CVS root I can use CVS import to > load it. If you "Repocopy" the files, the history will stay intact. Basically move his CVS/ files to your repository, and add appropriate entries stuff. LER > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Integrating libpqxx
On Wed, 2002-06-12 at 19:41, Bruce Momjian wrote: > Larry Rosenman wrote: > > > > > > I think we will just give you CVS access. Not sure how to get the CVS > > > history. I think if you send me the CVS root I can use CVS import to > > > load it. > > If you "Repocopy" the files, the history will stay intact. Basically > > move his CVS/ files to your repository, and add appropriate entries > > stuff. > > Ewe, appropriate entries? What I did on a RANCID install was to just add the CVS/ stuff, but I'm not sure with your scripts and stuff what else needs done. You might ask Marc Fournier as I think he knows how the FreeBSD folks do RepoCopies. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] First cut at SSL documentation
* Bruce Momjian <[EMAIL PROTECTED]> [020613 21:49]: > Bear Giles wrote: > > > Sorry, there is a newer version. I will use that one. > > > > You may want to hold off on that - I've been busy lately and haven't had > > a chance to revisit the documentation or change some of the literal constants > > to numeric constants, but it's been on my "to do" list. > > OK, thanks. I will hold off on the docs part. > > Sorry it has taken me so long to get to these SSL patches (my vacation). > I am doing them now. > > > The latter didn't affect the other patches since I planned on doing a > > latter-day patch anyway, but the documentation may need some big changes > > to emphasize that the rule that it's "use SSH tunnels if you just want > > to prevent eavesdropping, use SSL directly if you need to firmly establish > > the identity of the server or clients." > > > > (And sorry about responding via the lists, but your mail server doesn't > > like to talk to cable modem users.) > > Sorry about the block. RBL+ has been much more effective lately, and it > is because they are blocking more dialup users. This the first false > positive I have gotten from them. You can use [EMAIL PROTECTED] or > route your email through west.navpoint.com. I will see if I can pass > your IP through. I can do it in my blacklist, but I am not sure that > works for RBL+. If you are using sendmail, the access file overrides the RBL, if you set delay checks in the MC file. I can help if you are using sendmail. LER > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 > > ---(end of broadcast)--- > TIP 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] What is wrong with hashed index usage?
On Fri, 2002-06-21 at 11:51, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > > How about an elog(NOTICE) for hash use? > > > > I don't think that's appropriate. > > I was thinking of this during CREATE INDEX ... hash: > > NOTICE: Hash index use is discouraged. See the CREATE INDEX > reference page for more information. > > Does anyone else like/dislike that? I dislike it. Some clients/dba's will wonder why we even have them. Why should we bug the DBA on EVERY index that is a hash? I know I personally hate the FreeBSD linker warnings about certain functions, and don't like that precedent. -- 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] What is wrong with hashed index usage?
On Fri, 2002-06-21 at 15:12, Bruce Momjian wrote: > Larry Rosenman wrote: > > On Fri, 2002-06-21 at 11:51, Bruce Momjian wrote: > > > Tom Lane wrote: > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > > > > > > > > > > How about an elog(NOTICE) for hash use? > > > > > > > > I don't think that's appropriate. > > > > > > I was thinking of this during CREATE INDEX ... hash: > > > > > > NOTICE: Hash index use is discouraged. See the CREATE INDEX > > > reference page for more information. > > > > > > Does anyone else like/dislike that? > > I dislike it. Some clients/dba's will wonder why we even have them. > > > > Why should we bug the DBA on EVERY index that is a hash? > > > > I know I personally hate the FreeBSD linker warnings about certain > > functions, and don't like that precedent. > > OK, that's enough of a negative vote for me. So you feel the > documentation change is enough? Tom thinks so too. Yup. -- 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] test 2, first failed ...
On Fri, 2002-06-21 at 22:06, Marc G. Fournier wrote: > > Okay, just did a series of upgrades to the server to hopefully speed up > delivery a bit ... 6minutes more reasonable? let's see if it keeps up, > mind you ... Thanks, Marc. I assume this is in response to my note about the multi-hour delay? LER > > On Fri, 21 Jun 2002, Marc G. Fournier wrote: > > > > > ignore this one ... > > > > > > ---(end of broadcast)--- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to [EMAIL PROTECTED] so that your > > message can get through to the mailing list cleanly > > > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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] Buffer Management
On Tue, 2002-06-25 at 09:09, Tom Lane wrote: > Curt Sampson <[EMAIL PROTECTED]> writes: > > So, while we're at it, what's the current state of people's thinking > > on using mmap rather than shared memory for data file buffers? > [snip] > > (Hey Marc, can one do mmap in a BSD jail?) I believe the answer is YES. I can send you the man pages if you want. > > 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] Postgres idea list
On Wed, 2002-06-26 at 13:50, Josh Berkus wrote: > > BTW, does anyone on this list know about Command Prompt, Inc.'s tools? There > seems to be a lot of duplicte development going on in the commercial space. I know for my PERSONAL stuff, commercial tools ($$) mean I don't even bother. I have some consulting clients, but using pay for stuff generally won't work for them, plus I can't usually afford the fees for my own use, so therefore are not conversant with the commercial tools. Nothing against them, but... Just my $.02 worth. -- 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] Database comparison ideas
On Wed, 2002-06-26 at 20:54, Josh Berkus wrote: > > Dann, > > > From a growth standpoint, I think it is a much better idea to focus on > > their strong points. Look at the things each competitor can do best. > > Try to think of ways to get the same functionality from PostgreSQL. If > > it is impossible [or currently infeasible] to meet the functionality, > > then close the gap. > > You are, of course, correct. We will have to prioritize which "gaps" mean > the most to us. For example, if I was to make a "top six list": > > -- Lack of comprehensive GUI admin tools > -- Lack of replication and point in time recovery > -- PL/pgSQL does not 100% replace PL/SQL or T-SQL Stored Procedures > -- Miscellaneous speed/optimization issues > -- Need good GUI installer, including installer for Postgres+PHP+Apache > -- Win32 Port I know I (not knowing Oracle PL/SQL) have a hard time find enough docs on PL/pgSQL, even with buying Bruce's and the German PG Developers books. I'm personally having a hard time learning all the in's and out's of the trigger/rule stuff. I know I can use more of them, but have a hard time. -- 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] Virus Emails
On Sun, 2002-07-28 at 20:10, Marc G. Fournier wrote: > > God, I go through 200+ of those almost daily as moderator ... imagine if > we had the lists open? :) I picked up a copy of McAfee's vscan for FreeBSD from one of my contract people, and have amavisd-milter running to prevent them from even getting in the door. Mayhaps pgsql.org should do the same? > > > On Sat, 27 Jul 2002, Christopher Kings-Lynne wrote: > > > Hi guys, > > > > I seem to be getting virus emails that pretend to be one of your guys. eg. > > I get them from T.Ishii and N.Conway, etc. Anyone out there on the list who > > should perhaps scan their computer? :) > > > > Chris > > > > > > > > ---(end of broadcast)--- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > > ---(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
Re: [HACKERS] Virus Emails
Try their corporate sales droids If you can't find one, I'll ask my contract client LER On Tue, 2002-07-30 at 13:20, Marc G. Fournier wrote: > > Okay, this is sweet ... but can someone tell me where I 'Buy' a copy of > uvscan? I've searched McAfee, but can't seem to find it in their eStore > anywhere ... > > > On 28 Jul 2002, Larry Rosenman wrote: > > > On Sun, 2002-07-28 at 20:10, Marc G. Fournier wrote: > > > > > > God, I go through 200+ of those almost daily as moderator ... imagine if > > > we had the lists open? :) > > I picked up a copy of McAfee's vscan for FreeBSD from one of my contract > > people, and have amavisd-milter running to prevent them from even > > getting in the door. > > > > Mayhaps pgsql.org should do the same? > > > > > > > > > > > > > On Sat, 27 Jul 2002, Christopher Kings-Lynne wrote: > > > > > > > Hi guys, > > > > > > > > I seem to be getting virus emails that pretend to be one of your guys. eg. > > > > I get them from T.Ishii and N.Conway, etc. Anyone out there on the list who > > > > should perhaps scan their computer? :) > > > > > > > > Chris > > > > > > > > > > > > > > > > ---(end of broadcast)--- > > > > TIP 5: Have you checked our extensive FAQ? > > > > > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > > > > > > > > > > ---(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 > > > > -- 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] Virus Emails
I'll ask my contract what they paid On Wed, 2002-07-31 at 00:00, Marc G. Fournier wrote: > > the only thing I've found so far (I've email'd their sales guy, but > haven't heard back yet) on their site is a 'calculator' that depends on > number of users ... for the University I work out, I believe the cost came > out to something like $99kUS, and I went low on my figures for # of users > :) > > Thank god there is more then just McAfee out there .. unless those #'s are > wrong, am definitely going to be looking at alternatives ... > > On Wed, 31 Jul 2002, Christopher Kings-Lynne wrote: > > > I would also like to know this! They don't mention it anywhere on their > > site! > > > > Chris > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier > > > Sent: Wednesday, 31 July 2002 2:20 AM > > > To: Larry Rosenman > > > Cc: Christopher Kings-Lynne; [EMAIL PROTECTED] > > > Subject: Re: [HACKERS] Virus Emails > > > > > > > > > > > > Okay, this is sweet ... but can someone tell me where I 'Buy' a copy of > > > uvscan? I've searched McAfee, but can't seem to find it in their eStore > > > anywhere ... > > > > > > > > > On 28 Jul 2002, Larry Rosenman wrote: > > > > > > > On Sun, 2002-07-28 at 20:10, Marc G. Fournier wrote: > > > > > > > > > > God, I go through 200+ of those almost daily as moderator ... > > > imagine if > > > > > we had the lists open? :) > > > > I picked up a copy of McAfee's vscan for FreeBSD from one of my contract > > > > people, and have amavisd-milter running to prevent them from even > > > > getting in the door. > > > > > > > > Mayhaps pgsql.org should do the same? > > > > > > > > > > > > > > > > > > > > > > > On Sat, 27 Jul 2002, Christopher Kings-Lynne wrote: > > > > > > > > > > > Hi guys, > > > > > > > > > > > > I seem to be getting virus emails that pretend to be one of > > > your guys. eg. > > > > > > I get them from T.Ishii and N.Conway, etc. Anyone out > > > there on the list who > > > > > > should perhaps scan their computer? :) > > > > > > > > > > > > Chris > > > > > > > > > > > > > > > > > > > > > > > > ---(end of > > > broadcast)--- > > > > > > TIP 5: Have you checked our extensive FAQ? > > > > > > > > > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > > > > > > > > > > > > > > > > > > ---(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 5: Have you checked our extensive FAQ? > > > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > > > > > > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [GENERAL] [HACKERS] Linux Largefile Support In Postgresql RPMS
On Tue, 2002-08-13 at 03:42, Mark Kirkwood wrote: > Andrew Sullivan wrote: > > >On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote: > > > >>I'm actually amazed that postgres isn't already using large file > >>support. Especially for tools like dump. > >> > > > >Except it would only cause confusion if you ran such a program on a > >system that didn't itself have largefile support. Better to make the > >admin turn all these things on on purpose, until everyone is running > >64 bit systems everywhere. > > > >A > > > Ah yes ... extremely good point - I had not considered that. > > I am pretty sure all reasonably current (kernel >= 2.4) Linux distros > support largefile out of the box - so it should be safe for them. > > Other operating systems where 64 bit file access can be disabled or > unconfigured require more care - possibly (sigh) 2 binary RPMS with a > distinctive 32 and 64 bit label ...(I think the "big O" does this for > Solaris). Then, of course, there are systems where Largefiles support is a filesystem by filesystem (read mountpoint by mountpoint) option (E.G. OpenUNIX). I think this is going to be a pandoras 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 ---(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] Open 7.3 items
On Fri, 2002-08-16 at 09:51, Ross J. Reedstrom wrote: > On Fri, Aug 16, 2002 at 10:21:12AM -0400, Vince Vielhaber wrote: > > > RPMs aren't a good enough reason to put it in. All features aren't > > installed in an RPM, why would this need to? Besides, anything that > > is runtime configurable can end up getting its default changed on a > > whim. Then again as long as 7.2.1 is stable enough for me there's > > no reason to upgrade 'cuze I damn sure ain't going back and changing > > all sorts of programs and scripts that have global users. > > So, Vince, do you have problems with the various GUC based optimizer > hooks getting set to other than the default? I'd think you'd notice > if suddenly indexscans all went away, or any of these: > > #enable_seqscan = true > #enable_indexscan = true > #enable_tidscan = true > #enable_sort = true > #enable_nestloop = true > #enable_mergejoin = true > #enable_hashjoin = true > > My point is that your resistance to a GUC controlled runtime configurable > on the basis of 'it might get changed accidently' makes little sense to > me, given all the other runtime config settings that never do get changed. > What makes you think this one will be more susceptible to accidental > flipping? > > I'm not sure who's 'whim' it is that your afraid of: perhaps you have a > paticularly sadistic DBA to deal with? ;-) And of course, this being > free software and all, noone is forcing an upgrade on you. AND, I thought the general consensus was **AWAY** from configure time directives and to GUC variables whenever **POSSIBLE**. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposed GUC Variable
On Tue, 2002-08-27 at 15:54, Bruce Momjian wrote: > > I had an idea on this. It seems pretty pointless to show a query error > without a query, but some queries are very large. > > How about if we print only the first 80 characters of the query, with > newlines, tabs, and spaces reduced to a single space, and send that as > LOG to the server logs. That would give people enough context, and > prevent us from having another GUC variable. Not necessarily giving enough context. I know I've had program generated query's that were syntactically invalid WAY after the 80th character. If you print ANY of the query, you should print all of it. Look at the code in elog.c that does the syslog splitting. LER > > --- > > Gavin Sherry wrote: > > Hi all, > > > > Quick hack while eating a sandwich. > > > > template1=# select * frum; > > ERROR: parser: parse error at or near "frum" at character 10 > > ERROR QUERY: select * frum; > > > > Now, I did say quick hack. 'ERROR QUERY' isn't a new error level I just > > strcat() it to buf_msg in elog() if debug_print_error_query is > > true. Question: from Chris's request it doesn't sound like there is much > > use writing this to the client. Does everyone else feel the same way? > > > > If so, I'll patch it up and send off. > > > > Gavin > > > > On Thu, 22 Aug 2002, Bruce Momjian wrote: > > > > > > > > Someone asked for that recently, and the email is in my mailbox for > > > consideration. I think it is a great idea, and we have > > > debug_query_string that holds the current query. You could grab that > > > from elog.c. Added to TODO: > > > > > > * Add GUC parameter to print queries that generate errors > > > > > > --- > > > > > > Christopher Kings-Lynne wrote: > > > > Hi, > > > > > > > > My primary use of Postgres is as the backend database for a busy web site. > > > > We have a cron job that just emails us the tail of our database, php, apache > > > > logs every night. That way we can see some problems. > > > > > > > > These logs almost always contain some errors. For instance, this is what I > > > > see at the moment: > > > > > > > > 2002-08-22 19:21:57 ERROR: pg_atoi: error in "334 - 18k": can't parse " - > > > > 18k" > > > > > > > > Now there's plenty of places that accept numeric input in the site and > > > > obviously there's a bug in some script somewhere that's not filtering the > > > > input properly or something. However - the error message above is useless > > > > to me!!! > > > > > > > > So, what I'd like to propose is a new GUC variable called > > > > 'debug_print_query_on_error' or something. Instead of turning on > > > > debug_print_query and having my logs totally spammed up with sql, this GUC > > > > variable would only print the query if an actual ERROR occurred. This way I > > > > could nail the error very quickly by simply finding the query in my > > > > codebase. > > > > > > > > Is this possible? At the stage of processing where the elog(ERROR) occurs, > > > > do we still have access to the original query string? > > > > > > > > Comments? > > > > > > > > Chris > > > > > > > > > > > > ---(end of broadcast)--- > > > > TIP 4: Don't 'kill -9' the postmaster > > > > > > > > > > > > > > > > ---(end of broadcast)--- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > > > -- > 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 > > ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Proposed GUC Variable
On Tue, 2002-08-27 at 16:05, Bruce Momjian wrote: > Larry Rosenman wrote: > > On Tue, 2002-08-27 at 15:54, Bruce Momjian wrote: > > > > > > I had an idea on this. It seems pretty pointless to show a query error > > > without a query, but some queries are very large. > > > > > > How about if we print only the first 80 characters of the query, with > > > newlines, tabs, and spaces reduced to a single space, and send that as > > > LOG to the server logs. That would give people enough context, and > > > prevent us from having another GUC variable. > > Not necessarily giving enough context. I know I've had program > > generated query's that were syntactically invalid WAY after the 80th > > character. > > > > If you print ANY of the query, you should print all of it. Look at the > > code in elog.c that does the syslog splitting. > > But we should have some default to print some of the query, because > right now we print none of it. I am not saying it is perfect, but it is > better than what we have, and is a reasonable default. On an error, you may not be able to reproduce it. Why not print the whole query to the log? I don't see a reason for truncating it at 80 chars. IMHO, of course. -- 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] Proposed GUC Variable
On Tue, 2002-08-27 at 16:14, Bruce Momjian wrote: > Larry Rosenman wrote: > > > But we should have some default to print some of the query, because > > > right now we print none of it. I am not saying it is perfect, but it is > > > better than what we have, and is a reasonable default. > > On an error, you may not be able to reproduce it. Why not print the > > whole query to the log? > > > > I don't see a reason for truncating it at 80 chars. > > > > IMHO, of course. > > Because every typo query, every syntax error of a user in psql would > appear in your logs. That seems excessive. Already the ERROR line > appears in the logs. Do we want to see their bad query too? > > My concern is that long queries could easily bulk up the logs to the > point where the actual important log messages would be lost in the fog. Hmm. I think the 80 should be a GUC variable (and also settable from SQL SET as well), and the 80 should probably be higher. And, maybe send the full query at a different Syslog(3) level. -- 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] Proposed GUC Variable
On Tue, 2002-08-27 at 17:30, Ross J. Reedstrom wrote: > On Tue, Aug 27, 2002 at 06:08:40PM -0400, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > But we should have some default to print some of the query, > > > > Why? So far you've been told by two different people (make that three > > now) that such a behavior is useless, and no one's weighed in in its > > favor ... > > I agree that a 'trimmed' query is likely to be useless, but the idea of > printing the query on ERROR is a big win for me: right now I'm logging > _all_ queries on our development machine (and sometimes on our production > machine. when there's trouble) so my logs would get considerably smaller. I agree with printing the query on error... just not limiting it to 80 characters by default. > > A settable trim length would probably be a good idea, I suppose, for > those slinging 'bytea' and toasted texts around. Yes, but the default should be NO TRIM or in 1K-4K range. IMHO -- 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] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Tue, 2002-08-27 at 23:29, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, patch attached. It was actually easier than I thought. We have to > > decide if we are going to remove the old syntax in 7.4. > > I'd say "no". There's no compelling reason to break backward > compatibility here --- certainly a couple more productions in gram.y > isn't enough reason. I agree here. Why intentionally break something that doesn't violate standards, and would cause people to have to look at all their queries. I personally hope y'all do *NOT* remove the old syntax. > > But I think it'd be sufficient to document only the new syntax. Why? If both old and new are acceptable, why not document it? (Just curious, I'm not wedded to it). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 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] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wed, 2002-08-28 at 08:52, Bruce Momjian wrote: > Larry Rosenman wrote: > > On Tue, 2002-08-27 at 23:29, Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > OK, patch attached. It was actually easier than I thought. We have to > > > > decide if we are going to remove the old syntax in 7.4. > > > > > > I'd say "no". There's no compelling reason to break backward > > > compatibility here --- certainly a couple more productions in gram.y > > > isn't enough reason. > > I agree here. Why intentionally break something that doesn't violate > > standards, and would cause people to have to look at all their queries. > > I personally hope y'all do *NOT* remove the old syntax. > > > > > > But I think it'd be sufficient to document only the new syntax. > > > Why? If both old and new are acceptable, why not document it? > > (Just curious, I'm not wedded to it). > > Well, showing both versions adds confusion for no good reason, it > doesn't promote one over the other, and if we decide to get rid of the > old syntax someday, we can't do it. Why the h*ll are you insistent on REMOVING the old syntax? I see no good reason to remove it, and per TGL, the addition of the couple(few?) rules in the grammar is negligible. I sort of understand not documenting it, but please **DO NOT** remove the old syntax without a damn good reason. -- 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: [PATCHES] [HACKERS] Proposed GUC Variable
On Wed, 2002-08-28 at 14:05, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Gavin Sherry writes: > > > > > Attached is the patch. debug_print_error_query is set to false by default. > > > > > > For want of a better phrase, I've prepended 'original query: ' to the > > > error message to highlight why it is in the log. > > > > >From your resident How-To-Name-Stuff Nitpicker: > > > > 1. The names of the debug_* GUC variables are leftovers from the pre-GUC > > era and the names where left to include "debug" in them because at the > > time it wasn't clear whether the implementation had more than server-code > > debugging quality. New variables should be named log_*. > > Agreed. They are not really _debug_ for the server, but debug for user > apps; should be "log". > > > > 2. Unless you are only logging queries, the correct term is "statement" or > > "commmand". Statements are defined in the SQL standard to end at the > > semicolon, but if you're logging whatever the client passed in (which may > > contain multiple statements) then "command" might be best. (consequently: > > log_command_on_error or something like that) > > Or log_statement_on_error. I think statement is better because we are > using that now for statement_timeout. > > > 3. Not sure what the "original" is for -- you're not transforming > > anything. > > Agreed. Just call it "Error query". Seems clear to me. What about rule(s) transformation(s)? Will we see the real query or the transformed query? -- 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] [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1?
On Wed, 2002-08-28 at 21:29, Robert Treat wrote: > > I think after the LIMIT and FOR UPDATE explanations (but before the note about > SELECT privilege) you could add a note that "for backwards compatibility > reasons the LIMIT and FOR UPDATE clauses are interchangeable" though maybe > interchangeable isn't the best word... How about "for backwards compatibility reasons the LIMIT and FOR UPDATE clauses can appear in either order, I.E. LIMIT 1 FOR UPDATE and FOR UPDATE LIMIT 1 are equivalent". > > > For COPY, we could just put the old syntax at the bottom of the manual > > page and mention it is depricated. > > In both cases I don't know that a detailed explination is needed, but a > mention of the different possibility and perhaps a suggestion to look at an > old version of the docs for complete details should go a long way. I suspect that Bruce's suggestion is best, modulo a spell check :-). > > Robert Treat -- 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] tweaking MemSet() performance
On Thu, 2002-08-29 at 18:53, Alvaro Herrera wrote: > En Thu, 29 Aug 2002 19:35:13 -0400 (EDT) > Bruce Momjian <[EMAIL PROTECTED]> escribió: > > > In your results it seems to suggest that memset() gets slower for longer > > buffer lengths, and a for loop starts to win at longer sizes. Should I > > pull out my Solaris kernel source and see what memset() is doing? > > No, because memset() belongs to the libc AFAICS... Do you have source > code for that? and if you do, what vintage is it? I believe Solaris has mucked with stuff over the last few rev's. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] Proposed GUC Variable
On Thu, 2002-08-29 at 19:04, Gavin Sherry wrote: > On Thu, 29 Aug 2002, Tom Lane wrote: > > > Robert Treat <[EMAIL PROTECTED]> writes: > > > One of my users is generating a notice message --> NOTICE: Adding > > > missing FROM-clause entry for table "msg202" It might be helpful to > > > dump out the query on notice messages like this, and it looks like a > > > simple change as far as elog.c and guc.c are concerned, but would this > > > be overkill? > > > > Hm. Maybe instead of a boolean, what we want is a message level > > variable: log original query if it triggers a message >= severity X. > > That's a pretty good idea. Now, what format will the argument take: text > (NOTICE, ERROR, DEBUG, etc) or integer? The increasing severity is clear > with numbers but the correlation to NOTICE, ERROR etc is undocumented > IIRC. On the other hand, the textual form is clear but INFO < NOTICE < > WARNING < ERROR < FATAL, etc, is note necessarily obvious. (Also, with the > textual option the word will need to be converted to the corresponding > number by the GUC code). > > Naturally, the problem with each option can be cleared up with > documentation. my gut feeling is use the words. -- 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] Running postgres on a read-only file system
On Fri, 2002-08-30 at 16:34, Tyler Mitchell wrote: > > >On Fri, Aug 30, 2002 at 02:08:59PM -0700, Tyler Mitchell wrote: > >> > >> I know that I need to at least get some more understanding on the > process > >> that takes place. > > >The problem is that PostgreSQL doesn't have a "read only" mode. So > >you can't really do it this way. > > Okay, that answers one of my questions, thanks Andrew. Is this something > that others may be interested in? Is it realistic to ask that it be added > to the TODO list? > What kind of writes occur normally, how does file locking work. Could you > direct me to other resources on this for postgresql? > > > > >Is there a way to make a RAMDISK on Win32? If so, Tom Lane's > >suggestion is probably the best one. Set up a RAMDISK, put your data > >directory there, and presto. Of course, that means you need enough > >physical memory to hold the database, which might cause problems. > > > >What about using the CD-ROM to copy a version of the database onto > >the hard drive? You could delete it when your application shuts > >down, I guess; you'd still need that much free space for your db, > >though. > > Yes, both good ideas, we've been kicking these around. But we just wanted > to exhaust the possibilities before we "give in" :) > > One more idea, is it possible to "fake" a read-write file system. I.e. > supply the files that postgresql will be looking for? (I know it's a > stretch, but hey, this IS the "hackers" list) :) The problem is every query wants to write the clog files. -- 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] Bug in Makefile.shlib
On Wed, 2002-09-04 at 12:28, Tom Lane wrote: > Olivier PRENANT <[EMAIL PROTECTED]> writes: > > I think I figured why I can't buil plperl on unixware 711/OpenUnix 800. > > > It seems Makefile.shlib has changed between 722 and 73 and -z text has > > been added. > > Not hardly. The "-z text" option has been in there since at least 6.4. > 6.4's Makefile.shlib has > > ifeq ($(PORTNAME), unixware) > ... > LDFLAGS_SL:= -G -z text > ... > endif > > which was cribbed from even older shlib support in other files. We used > that up through 7.0 without any revisions. In 7.1 Makefile.shlib was > revised pretty heavily; 7.1 has a unixware section that is identical to > current sources, in particular > > LINK.shared += -Wl,-z,text -Wl,-h,$(soname) > > So I think this code is pretty well tested and removing the -z option > is more likely to break things than fix them. > > What misbehavior are you seeing exactly? see my post from ~2 weeks ago on -hackers with a 7.2.[12] problem. It flat doesn't work. I can dig the post up if you want. > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PL/Perl?
On Wed, 2002-09-04 at 17:54, Tom Lane wrote: > Larry Rosenman <[EMAIL PROTECTED]> writes: > > I upgraded PostgreSQL to 7.2.1 from a 7.2beta (yeah, I know). One of my > > users requested plperl, so I got it to createlang, but it SIGSEGV's on > > any simple perl. > > I was seeing the same with perl 5.6.1 and PG 7.2.* on HPUX 10.20. > However, I have just verified that perl 5.8.0 works okay with PG CVS tip > (not much testing, but it handles a simple plperl function). Could you > see whether 5.8.0 plays any nicer on your setup? Need to check with my user, I'll let ya know. 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl?
On Wed, 2002-09-04 at 19:41, Larry Rosenman wrote: > On Wed, 2002-09-04 at 17:54, Tom Lane wrote: > > Larry Rosenman <[EMAIL PROTECTED]> writes: > > > I upgraded PostgreSQL to 7.2.1 from a 7.2beta (yeah, I know). One of my > > > users requested plperl, so I got it to createlang, but it SIGSEGV's on > > > any simple perl. > > > > I was seeing the same with perl 5.6.1 and PG 7.2.* on HPUX 10.20. > > However, I have just verified that perl 5.8.0 works okay with PG CVS tip > > (not much testing, but it handles a simple plperl function). Could you > > see whether 5.8.0 plays any nicer on your setup? > Need to check with my user, I'll let ya know. > Well, I tried to install 5.8.0 on my 8.0.1 (beta) system, and blew cc up with an internal compiler error. I'll have to wait for Caldera to fix that. Sorry. -- 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] PL/Perl?
On Thu, 2002-09-05 at 15:16, Larry Rosenman wrote: > On Wed, 2002-09-04 at 19:41, Larry Rosenman wrote: > > On Wed, 2002-09-04 at 17:54, Tom Lane wrote: > > > Larry Rosenman <[EMAIL PROTECTED]> writes: > > > > I upgraded PostgreSQL to 7.2.1 from a 7.2beta (yeah, I know). One of my > > > > users requested plperl, so I got it to createlang, but it SIGSEGV's on > > > > any simple perl. > > > > > > I was seeing the same with perl 5.6.1 and PG 7.2.* on HPUX 10.20. > > > However, I have just verified that perl 5.8.0 works okay with PG CVS tip > > > (not much testing, but it handles a simple plperl function). Could you > > > see whether 5.8.0 plays any nicer on your setup? > > Need to check with my user, I'll let ya know. > > > Well, I tried to install 5.8.0 on my 8.0.1 (beta) system, and blew cc up > with an internal compiler error. I'll have to wait for Caldera to fix > that. Sorry..... Well, this system has GCC as well, and GCC groked PERL 5.8.0, and, TA DA, PL/PERL works with 5.8.0... THanks all... > > > -- > 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]) > -- 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] 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])
[HACKERS] PG_DUMP and Adding columns/Types
Looking at a 7.2.3 dump of a database I've been using for development, I noticed that a type that was used in a ALTER TABLE ADD COLUMN (for an existing table) was CREATE TYPE **AFTER** the CREATE TABLE for said table. I suspect this will give me grief on reload. (I can get around it, but I thought I'd mention the issue). Basically, I defined a comments table, then decided I wanted to use the contrib/tsearch module, so I added the contrib/tsearch stuff, and then did a ALTER TABLE ADD COLUMN comments_idx txtidx. In the pg_dump (and pg_dump -s), I note that the CREATE TYPE for txtidx happens AFTER the CREATE TABLE comments. I haven't tried to reload this dump script yet. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
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] PL/Perl and Perl 5.8
> ='' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize > > =8 > alignbytes=4, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -L/usr/local/lib' > libpth=/usr/local/lib /lib /usr/lib > libs=-lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt > perllibs=-ldl -lm -lpthread -lc -lcrypt > libc=/lib/libc-2.2.5.so, so=so, useshrplib=true, libperl=libperl.so.5.8.0 > gnulibc_version='2.2.5' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' > cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' > > > Characteristics of this binary (from libperl): > Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_ > > CONTEXT > Built under linux > Compiled at Sep 14 2002 17:36:21 > @INC: > /etc/perl > /usr/local/lib/perl/5.8.0 > /usr/local/share/perl/5.8.0 > /usr/lib/perl5 > /usr/share/perl5 > /usr/lib/perl/5.8.0 > /usr/share/perl/5.8.0 > /usr/local/lib/site_perl > > > ---(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 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 > 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)
ifier list: ExceptionalCondition UX:acomp: WARNING: "ascii_and_mic.c", line 43: syntax error: empty declaration UX:acomp: WARNING: "ascii_and_mic.c", line 43: syntax error: empty declaration UX:acomp: ERROR: "ascii_and_mic.c", line 44: Syntax error before or at: && UX:acomp: ERROR: "ascii_and_mic.c", line 44: parameter not in identifier list: ExceptionalCondition UX:acomp: WARNING: "ascii_and_mic.c", line 44: syntax error: empty declaration UX:acomp: WARNING: "ascii_and_mic.c", line 44: syntax error: empty declaration UX:acomp: WARNING: "ascii_and_mic.c", line 46: function prototype parameters must have types UX:acomp: ERROR: "ascii_and_mic.c", line 46: parameter not in identifier list: pg_ascii2mic UX:acomp: ERROR: "ascii_and_mic.c", line 48: Syntax error 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
Re: [HACKERS] FreeBSD 4.7: BETA3 (from port): regression failures...
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). LER *** ./expected/geometry-positive-zeros-bsd.out Tue Sep 12 16:07:16 2000 --- ./results/geometry.out Mon 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.out Mon Oct 28 00:15:33 2002 *** *** 537,549 SELECT (timestamp with time zone 'today' = (timestamp with time zone 'tomorrow' - interval '1 day')) as "True"; True -- ! t (1 row) SELECT (timestamp with time zone 'tomorrow' = (timestamp with time zone 'yesterday' + interval '2 days')) as "True&qu
[HACKERS] FreeBSD 4.7: BETA3 (from port): regression failures...
#x27;::text AS two, unique1, unique2, stringu1 FROM onek WHERE unique1 > 60 AND unique1 < 63 ORDER BY unique1 LIMIT 5; two | unique1 | unique2 | stringu1 -+-+-+-- ! | 61 | 560 | JC ! | 62 | 633 | KC ! (2 rows) SELECT ''::text AS three, unique1, unique2, stringu1 FROM onek WHERE unique1 > 100 ORDER BY unique1 LIMIT 3 OFFSET 20; three | unique1 | unique2 | stringu1 ---+-+-+-- !| 121 | 700 | RE !| 122 | 519 | SE !| 123 | 777 | TE ! (3 rows) SELECT ''::text AS zero, unique1, unique2, stringu1 FROM onek WHERE unique1 < 50 --- 7,34 ORDER BY unique1 LIMIT 2; two | unique1 | unique2 | stringu1 -+-+-+-- ! (0 rows) SELECT ''::text AS five, unique1, unique2, stringu1 FROM onek WHERE unique1 > 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 | RIAAAA ! | 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
&g
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),
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) > > >
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] good news: FreeBSD 4.7: all passed (with Bruce's
On Tue, 2002-10-29 at 12:13, Bruce Momjian wrote: > > Ports list updated: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/supported-platforms.html except for the version of PG :-) > > --- > Larry Rosenman wrote: > > 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 > > > > -- > 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
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]
