Re: [HACKERS] more compile warnings
On Fri, Dec 06, 2002 at 11:16:30PM -0500, Bruce Momjian wrote: > > I use: > > -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align Some other useful ones are -pedantic -W -Wfloat-equal -Wshadow -Wcast-qual -Wwrite-strings -Wconversion -Wsign-compare -Wsign-promo. > You would think that would catch it. My problem is that I am compiling > with -O0, because I compile all day and I don't care about optimization. > In this case, the -O3 is doing some optimization that catches the > problem, while -O0 does not. Interesting. Even -O catches it. Last time I checked (which was admittedly some time ago) all the interesting analysis that could give you new warnings was done by -O; -O2 mostly involves the back-end, and -O3 adds pretty much nothing except aggressive inlining. Which was more likely to trigger compiler bugs at the time than to find anything in your code. Jeroen ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] more compile warnings
Dann Corbit wrote: > Instead of just assigning a value, it means it is conceivable that a > path allows undefined behavior. Example: > > ... > int y; > if (x < 5) >y = 3; > if (x > 5) >y = 1; > > What happens if x == 5? Then y is indeterminate. > Sometimes, the flow analysis just gets confused and it really will be > initialized along every path. But at least it bears checking. Hence > the warning. Yes, I looked at the code, and they are legitimate warnings. > I like to use -W -Wall -ansi -pedantic -O3 I use: -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align You would think that would catch it. My problem is that I am compiling with -O0, because I compile all day and I don't care about optimization. In this case, the -O3 is doing some optimization that catches the problem, while -O0 does not. Interesting. Even -O catches it. -- 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
Re: [HACKERS] more compile warnings
> -Original Message- > From: Bruce Momjian [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 06, 2002 7:58 PM > To: Joe Conway > Cc: [EMAIL PROTECTED]; PostgreSQL-development > Subject: Re: [HACKERS] more compile warnings > > > Rod, can you comment on these warnings Joe Conway's compiler > is showing? I don't see the warnings with gcc, but clearly > they look like problems. > > I can just assign a NULL on definition, but I thought you > should take a look. > > -- > - > > Joe Conway wrote: > > Hi Bruce, > > > > I just sync'd up/make clean/make all and get this: > > > > gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations > > -I../../../src/include -c -o typecmds.o typecmds.c -MMD > > typecmds.c: In function `AlterDomainAddConstraint': > > typecmds.c:1237: warning: `ccbin' might be used > uninitialized in this > > function > > typecmds.c: In function `get_rels_with_domain': > > typecmds.c:1450: warning: `rtc' might be used uninitialized > in this function Instead of just assigning a value, it means it is conceivable that a path allows undefined behavior. Example: ... int y; if (x < 5) y = 3; if (x > 5) y = 1; What happens if x == 5? Then y is indeterminate. Sometimes, the flow analysis just gets confused and it really will be initialized along every path. But at least it bears checking. Hence the warning. I like to use -W -Wall -ansi -pedantic -O3 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] IPv6 patch rejected
I now have the INETv6 patch working using IPv4 on my machine, and I don't have IPv6 enabled in my kernel. Tomorrow, I will review the entire patch for portability issues, then post it so others can test it. I am pretty sure it is going to fail if your machine isn't INET6 aware, which may be many. --- > > The INETv6 patch was rejected because of this report, and an error on > > postmaster startup from BSD/OS: > > > > LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor > > servname provided, or not known > > > > Please submit a new patch that addresses these issues. I can work with > > you to do testing. > > > > --- > > > > Joe Conway wrote: > > > Bruce Momjian wrote: > > > > Fixing now. This just isn't my night --- another patch with a missing > > > > file. > > > > > > > > > > OK - I can run configure and make now, but I'm getting these warnings: > > > > > > In file included from ../../../../src/include/libpq/libpq.h:22, > > > from printtup.c:20: > > > ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' declared > > > inside parameter list > > > ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this > > > definition or declaration, which is probably not what you want. > > > ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' declared > > > inside parameter list > > > > > > lots of similar warnings to the above -- and: > > > > > > auth.c: In function `ClientAuthentication': > > > auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer type > > > gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations > > > -I../../../src/include -c -o crypt.o crypt.c -MMD > > > In file included from ../../../src/include/libpq/libpq.h:22, > > > from crypt.c:24: > > > > > > Joe > > > > > > > > > ---(end of broadcast)--- > > > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > > > > > > > > > -- > > > Nigel Kukard (Chief Executive Officer) > Lando Technologies Africa (Pty) Ltd > [EMAIL PROTECTED] www.lando.co.za > Tel: 083 399 5822 Fax: 086 1100036 > Hoheisen Park Bellville, Cape Town > National Internet Service Provider > > > The best language to use is the language that was designed for > what you want to use it for - 1997 > > > = > > Disclaimer > -- > The contents of this message and any attachments are intended > solely for the addressee's use and may be legally privileged and/or > confidential information. This message may not be retained, > distributed, copied or used if you are not he addressee of this > message. If this message was sent to you in error, please notify > the sender immediately by reply e-mail and then destroy the message > and any copies thereof. > > Opinions, conclusions and other information in this message may be > personal to the sender and is not that of Lando Technologies Africa > or any of it's subsideries, associated companies or principals and > is therefore not endorsed by any of the Lando groups of companies. > Due to e-maill communication being insecure, Lando groups of > companies do not guarantee confidentiality, security, accuracy or > performance of the e-mail. Any liability for viruses is excluded > to the fullest extent. > > -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] more compile warnings
Rod, can you comment on these warnings Joe Conway's compiler is showing? I don't see the warnings with gcc, but clearly they look like problems. I can just assign a NULL on definition, but I thought you should take a look. --- Joe Conway wrote: > Hi Bruce, > > I just sync'd up/make clean/make all and get this: > > gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations > -I../../../src/include -c -o typecmds.o typecmds.c -MMD > typecmds.c: In function `AlterDomainAddConstraint': > typecmds.c:1237: warning: `ccbin' might be used uninitialized in this function > typecmds.c: In function `get_rels_with_domain': > typecmds.c:1450: warning: `rtc' might be used uninitialized in this function -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] about store Large file.
I ask me, the store of large file like 2M in one field take to postgres a big work, you do that ? any of you do that before ? the sistem work fine or not ? Thanks for all -- Saludos Horacio Miranda. [EMAIL PROTECTED] PostgreSQL. Because life's too short to learn Oracle.:) Billy O'Connor IBM --> Immer Backup Machen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] hardware needed ?
Hi Eric, We've already done a fair amount of testing of PostgreSQL on Sparc hardware and Solaris, so it's probably not all that interesting... :-/ However, about an hour after you sent through your message, we received this one from Myk Melez. He's asking us if there is a publically available PostgreSQL server, and there isn't yet, so I'm wondering if you'd be willing to setup a PostgreSQL server on your Sparccenter 2000 and let anyone anywhere connect to it, for a while at least. We wouldn't want it to be extremely long term, as you never know what un-cool things people could decide to store in there, but it might be useful for a week or two after Myk's article becomes available for readers. Would you be interested in this? :-) Regards and best wishes, Justin Clift Original Message Subject: [GENERAL] publicly available PostGreSQL server? Date: Fri, 06 Dec 2002 12:33:10 -0800 From: Myk Melez <[EMAIL PROTECTED]> Organization: mozilla.org To: [EMAIL PROTECTED] Is there a publicly available PostGreSQL server? I'm co-writing an article for an online journal that includes information about Mozilla's upcoming database support, and I'd like to point readers to a PostGreSQL installation where they can try out an example app without having to install their own server. More info about database support in Mozilla: http://bugzilla.mozilla.org/show_bug.cgi?id=81653 -myk Eric Gentilini wrote: Hi all, I didn't find any other list compatible with this post, I hope it is the right place. I got a sparccenter 2000 (sun4d) few weeks ago and I wondered if the postgresql team was interested in testing postgres on it. It has only 2 CPUs at this time but I may get more cpu and system boards in the next month. I thought it would have been interesting to test postgres on uch an architecture. Are you interested ? Would you be interested ? It runs solaris 8 and linux, but linux doesn't support smp on sun4d :/ ... and since the kernel team doesn't work on sparc32 anymore, I thought it could be used by user-land software projects. The machine is located on an dsl lins 128/512kbps. seeya a+ -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Patch to make Turks happy.
Are you 64-bit s390?
We have OS/390 patches in 7.4 but they were judged too risky for 7.3.
Attached is the patch. Comment is:
revision 1.103
date: 2002/11/22 01:13:16; author: tgl; state: Exp; lines: +29 -2
TAS code originally written for s390 (32-bit) does not work for s390x
(64-bit). Fix it. Per report from Permaine Cheung.
---
Florian Weimer wrote:
> Nicolai Tufar <[EMAIL PROTECTED]> writes:
>
> > As far as I figured from the source code this function only deals
> > with cleaning up locale names and nothing else. Since all the locale
> > names are in plain ASCII I think it will be safe to use ASCII-only
> > lower-case conversion.
>
> Does PostgreSQL run on the UNIX subsystem of OS/390? ;-)
>
> (EBCDIC is a bit, uhm, strange. Only the decimal digits are
> consecutive the rest is a big mess.)
>
> --
> Florian Weimer [EMAIL PROTECTED]
> University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
> RUS-CERT fax +49-711-685-5898
>
> ---(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
Index: s_lock.h
===
RCS file: /cvsroot/pgsql-server/src/include/storage/s_lock.h,v
retrieving revision 1.102
retrieving revision 1.103
diff -c -c -r1.102 -r1.103
*** s_lock.h10 Nov 2002 00:33:43 - 1.102
--- s_lock.h22 Nov 2002 01:13:16 - 1.103
***
*** 63,69
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
! * $Id: s_lock.h,v 1.102 2002/11/10 00:33:43 momjian Exp $
*
*-
*/
--- 63,69
* Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
! * $Id: s_lock.h,v 1.103 2002/11/22 01:13:16 tgl Exp $
*
*-
*/
***
*** 150,156
#endif /* __arm__ */
! #if defined(__s390__) || defined(__s390x__)
/*
* S/390 Linux
*/
--- 150,157
#endif /* __arm__ */
!
! #if defined(__s390__) && !defined(__s390x__)
/*
* S/390 Linux
*/
***
*** 175,180
--- 176,207
}
#endif /* __s390__ */
+
+ #if defined(__s390x__)
+ /*
+ * S/390x Linux (64-bit zSeries)
+ */
+ #define TAS(lock)tas(lock)
+
+ static __inline__ int
+ tas(volatile slock_t *lock)
+ {
+ int _res;
+
+ __asm__ __volatile__(
+ " la 1,1 \n"
+ " lg 2,%2\n"
+ " slr 0,0 \n"
+ " cs 0,1,0(2)\n"
+ " lr %1,0\n"
+ : "=m"(lock), "=d"(_res)
+ : "m"(lock)
+ : "0", "1", "2");
+
+ return (_res);
+ }
+
+ #endif /* __s390x__ */
#if defined(__sparc__)
---(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] pg_conversion
Hi, What do the columns conforencoding and contoencoding refer to in pg_conversion? How would I convert those numbers to a string encoding name, just using SQL? Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
As someone who exists mainly as an active user (and part-time advocate/documentation tweaker), I have found the release of PostgreSQL 7.3 to be disappointing. The ensuing pseudo-flamewar on the various lists has been similarly disappointing. I was surprised, for instance, to receive a non-list email announcing the release of the software but then to have to wait for days actually to see it show up on the official (or even the advocacy) website in a news item. Even now it is not listed at PostgreSQL, Inc. Consider the pieces of the puzzle here: 1) an official website (http://www.postgresql.org/) 2) an advocacy website (http://advocacy.postgresql.org/) 3) official mailing lists 4) a separate email database 5) a developers' website (http://developers.postgresql.org/) 6) an official ftp site (ftp://ftp.postgresql.org/) 7) mirror websites 8) mirror ftp sites 9) a corporate website (http://www.pgsql.com/) While I have remained impressed with the software itself, the organization of these pieces has left much to be desired for the duration of my involvement as an end user. As someone who works in a small startup company, I am a frequent witness to both the advantages and disadvantages of the lack of a strong benevolent dictatorship in the form of management. I think one of the core problems with the advocacy and presentation of the PostgreSQL project is the fact that it has been a developer-centric project for quite some time, and that process, while there are drivers, does not tend to affect much other than the code. There does not seem to be a single, driving vision (or even a Board or consensus-based vision) behind the public face of PostgreSQL. Granted, when a project is entirely volunteer-based, the management and development are loose. I've noticed that in many such projects, web design and maintenance become very low priority, especially when left to groups of hackers. Witness GNU, Debian, and, I would say PostgreSQL: extremely spare official websites often intimidating and/or difficult for the newbie. I've wanted to see a bit more structure given to the PostgreSQL website, the release process, and various other portions of the project for quite some time, but often it seems as though such a structure would not even be welcome. As someone who has not had time to be a true developer on the project, I'm content to wait for the missing features I'd like to see. Still, I'm hoping that developers and advocates alike realize that the release process and these lists are in the public domain, and the way business is conducted affects the perceptions of users as much as the quality of the software or any amount of marketing. In any case, thanks for all the hard work. I actually thought the text of the email release I received was good and am working on the upgrade process now in my own environment. -tfo In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tom Lane) wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Peter Eisentraut wrote: > >> Marc G. Fournier writes: > >>> It isn't, but those working on -advocacy were asked to help come up with a > >>> stronger release *announcement* then we've had in the past ... > >> > >> Consider that a failed experiment. PostgreSQL is driven by the > >> development group and, to some extent, by the existing user base. The > >> last thing we need is a marketing department in that mix. > > > Peter, I understand your perspective, but I think you are in the > > minority on this one. > > I tend to agree with Peter. Not that we don't need a marketing > presence; we do (I think Great Bridge's marketing efforts are sorely > missed). But the point he is making is that the pgsql mailing lists > go to people who are generally unimpressed by marketing fluff. And > they're already "sold" on PG anyway. > > The right way to handle this next time is to generate a PR-style > press release to send to outside contacts, but to do our more > traditional, technically-oriented announcement on the mailing lists. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] Patch to make Turks happy.
Nicolai Tufar <[EMAIL PROTECTED]> writes: > As far as I figured from the source code this function only deals > with cleaning up locale names and nothing else. Since all the locale > names are in plain ASCII I think it will be safe to use ASCII-only > lower-case conversion. Does PostgreSQL run on the UNIX subsystem of OS/390? ;-) (EBCDIC is a bit, uhm, strange. Only the decimal digits are consecutive the rest is a big mess.) -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] GEQO Triggers Server Crash
Kris Jurka <[EMAIL PROTECTED]> writes: > [ GEQO doesn't work anymore in CVS tip ] Ugh. The proximate cause of this is the code I added recently to cache repeated calculations of the best inner indexscan for a given inner relation with potential outer relations. Since geqo_eval() releases all memory acquired during construction of a possible jointree, it releases the cached path info too. The next attempt to use the data fails. Naturally, ripping out the cache again doesn't strike me as an appealing solution. The narrowest fix would be to hack best_inner_indexscan() to switch into the context containing the parent RelOptInfo while it makes a cache entry. This seems kinda klugy but it would work. I wonder if we'd be better off not trying to reclaim memory in geqo_eval. Aside from presenting a constant risk of this sort of problem whenever someone hacks the optimizer, what it's really doing is discarding a whole lot of join cost estimates that are likely to be done over again in (some of) the following calls of geqo_eval. GEQO would certainly be a lot faster if we didn't release that info, and I'm not sure that the space cost would be as bad as the code comments claim. Any thoughts? This really just points up how messy memory management in the optimizer is at present. I wonder if anyone has ideas on improving it ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Q: "unknown expression type 108" ?
On Friday 06 December 2002 20:50, Tom Lane wrote: (B> Ian Barwick <[EMAIL PROTECTED]> writes: (B> > ERROR: ExecEvalExpr: unknown expression type 108 (B> (B> This is fixed as of yesterday --- see thread on (I think) pgsql-general (B> for the patch. (B (BMany thanks. Applied and appears to work :-) (B (BFor reference: (Bhttp://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&selm=2630.1039125066%40sss.pgh.pa.us (B (B (BIan Barwick ([EMAIL PROTECTED] (B (B (B (B---(end of broadcast)--- (BTIP 3: if posting/reading through Usenet, please send an appropriate (Bsubscribe-nomail command to [EMAIL PROTECTED] so that your (Bmessage can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
> -Original Message- > From: Josh Berkus [mailto:[EMAIL PROTECTED]] > Sent: 06 December 2002 17:45 > To: [EMAIL PROTECTED] > Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group > > > Dave, > > > > > > > BTW, we do coordinate with the Website development group > > > > When did that happen then? I think I must have blinked :-) > > Marc and Justin are periodically keeping the Advocacy group informed > of progress on wwwdevel, and we were asked to test it before. Vince > asked us for suggestions, too. > > It's not like Advocacy has so much time to mess around with > the Advocacy site that we need weekly updates from WWW as well ... Ahh, it's the other way round we don't see (advocacy -> www). > == > > Postges People: > > What really troubles me is that I'm seeing the *implication* > on this list that one or more people offered to help the WWW > team and were > rejected. If this is true, I'd like to see that person say so > explicitly and we can find out from Vince and Marc what > happened; if not, I think the insinuations about > "exclusiveness" by the WWW team are completely uncalled for. Yes, this worries me. We have very recently had a couple of new volunteers join the team who have been actively helping me with the new portal - I've certainly not heard of anyone being turned away. It was also not long ago that Vince solicited new design ideas from the community on -general. Wrt the closed status of the list, I think (please correct me if I'm wrong Marc/Vince) this is mainly because we try to keep it very focused. It is very much a developers meeting place where we *all* contribute heavily to the work. It is not a support list, or general discussion list. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Quick Help
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: > Messing about with ADD COLUMN... > I'm not certain how to re-evaluate the default expression for each > row? Basically you'll want to apply ExecEvalExpr (or perhaps ExecEvalExprSwitchContext) to the "cooked" expression tree. Look at the execution of per-row constraints in ADD CONSTRAINT; should be very very similar. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] SQL/MED spec for cross-database linkages
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes: > Having pulled that one, I discover it's actually the XML related spec. The > MED one is at: > ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-09-MED-2002-01.pdf Ah-hah, so the URL in the SIGMOD Record article is just wrong :-( Meanwhile, one of the authors sent me a copy privately (it helps to have shared an office at grad school ;-)) which I was about to offer around, but I guess we can just use the FTP link instead. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] possible libpq++ prob
Patrick Welche <[EMAIL PROTECTED]> writes: > WARNING: Message from PostgreSQL backend: > The Postmaster has informed me that some other backend > died abnormally and possibly corrupted shared memory. > Should I be able to cause this with a duff query? No. That's a backend bug, not a libpq++ bug. Let's see the query ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] hardware needed ?
Hi all, I didn't find any other list compatible with this post, I hope it is the right place. I got a sparccenter 2000 (sun4d) few weeks ago and I wondered if the postgresql team was interested in testing postgres on it. It has only 2 CPUs at this time but I may get more cpu and system boards in the next month. I thought it would have been interesting to test postgres on uch an architecture. Are you interested ? Would you be interested ? It runs solaris 8 and linux, but linux doesn't support smp on sun4d :/ ... and since the kernel team doesn't work on sparc32 anymore, I thought it could be used by user-land software projects. The machine is located on an dsl lins 128/512kbps. seeya a+ -- Eric GENTILINI ---(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/MED spec for cross-database linkages
On Fri, Dec 06, 2002 at 01:52:01PM -0500, Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > Found SQL/MED, Section 21 of ISO 9075-9. > > That's the old version, though. The new draft is at (digs out article) > http://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf > according to this article, but I'm not having any luck accessing that > URL. Let me email the authors and see if I can get a copy. > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? Having pulled that one, I discover it's actually the XML related spec. The MED one is at: ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-09-MED-2002-01.pdf There's a text version, as well (always nice for grepping): ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-09-MED-2002-01.txt Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] SQL/MED spec for cross-database linkages
On Fri, Dec 06, 2002 at 01:52:01PM -0500, Tom Lane wrote: > Rod Taylor <[EMAIL PROTECTED]> writes: > > Found SQL/MED, Section 21 of ISO 9075-9. > > That's the old version, though. The new draft is at (digs out article) > http://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf > according to this article, but I'm not having any luck accessing that > URL. Let me email the authors and see if I can get a copy. Hmm, seems you need to change protocols: ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf Ross ---(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] Q: "unknown expression type 108" ?
Ian Barwick <[EMAIL PROTECTED]> writes: > ERROR: ExecEvalExpr: unknown expression type 108 This is fixed as of yesterday --- see thread on (I think) pgsql-general for the patch. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] SQL/MED spec for cross-database linkages
Joe Conway <[EMAIL PROTECTED]> writes: > Do you think a proposal based on the SQL/MED spec would be entertained for > 7.4, or would the release after be a safer bet? The impression I get from this article is that SQL/MED is nontrivial. If you think you can get something useful going for 7.4, step right up --- but I think you should plan on being at it for awhile. In any case, a multi-step implementation plan would be a good idea. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SQL/MED spec for cross-database linkages
Rod Taylor <[EMAIL PROTECTED]> writes: > Found SQL/MED, Section 21 of ISO 9075-9. That's the old version, though. The new draft is at (digs out article) http://sqlstandards.org/SC32/WG3/Progression_Documents/FCD/4FCD1-14-XML-2002-03.pdf according to this article, but I'm not having any luck accessing that URL. Let me email the authors and see if I can get a copy. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SQL/MED spec for cross-database linkages
Tom Lane wrote: Joe, have you heard of a standard called SQL/MED? I came across a description of it the other day. You might think it's got some medical connotation, but actually the acronym is Management of External Data, and what it is is a standard spec for shipping chunks of SQL queries to remote servers. For instance, given SELECT * FROM a.foo, b.bar WHERE ... where a.foo is on a remote machine, the spec lays down how the local and remote servers can cooperate to execute this query intelligently --- including deciding where to execute various WHERE clauses to minimize the amount of data shipped. (The article I found was actually about how the new draft version of SQL/MED improves the protocol to let this sort of thing be done better; it seems the original spec only allowed retrieval of a whole table's contents.) This looks like it might be a great long-term replacement for dblink, and if it is standard, so much the better. Great! Thanks for the heads up. I see that Rod provided the reference in his post -- I'll go find it. The idea of expanding dblink to other RDBMSs is picking up steam. I've been conversing off list with someone who has a semi-working hacked version of dblink that uses JDBC in place of libpq. Do you think a proposal based on the SQL/MED spec would be entertained for 7.4, or would the release after be a safer bet? I'm not sure (since I haven't seen it yet) what I'm getting myself into ;-), but I might like to take it on since there seems to be a lot of interest. Joe Joe ---(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] [GENERAL] PostgreSQL Global Development Group
Dave, > > > > BTW, we do coordinate with the Website development group > > When did that happen then? I think I must have blinked :-) Marc and Justin are periodically keeping the Advocacy group informed of progress on wwwdevel, and we were asked to test it before. Vince asked us for suggestions, too. It's not like Advocacy has so much time to mess around with the Advocacy site that we need weekly updates from WWW as well ... == Postges People: What really troubles me is that I'm seeing the *implication* on this list that one or more people offered to help the WWW team and were rejected. If this is true, I'd like to see that person say so explicitly and we can find out from Vince and Marc what happened; if not, I think the insinuations about "exclusiveness" by the WWW team are completely uncalled for. -Josh Berkus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] possible libpq++ prob
I have a program which worked merrily under 1.3b1, but with 1.4devel I get the first query working (so connection OK), and the second query, which may well be wrong, getting me: DEBUG: reaping dead processes DEBUG: child process (pid 13025) was terminated by signal 11 LOG: server process (pid 13025) was terminated by signal 11 LOG: terminating any other active server processes DEBUG: CleanupProc: sending SIGQUIT to process 13022 WARNING: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. DEBUG: reaping dead processes DEBUG: child process (pid 13022) exited with exit code 1 LOG: all server processes terminated; reinitializing shared memory and semaphores Should I be able to cause this with a duff query? I'm now digging myself in further by trying to recompile the program which uses libpq++ - I don't think libpq++ works terribly well anymore but unfortunately I have to leave now before figuring out what pg_config.h includes may be needed to define eg DLLIMPORT etc. More later no doubt... Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SQL/MED spec for cross-database linkages
On Fri, 2002-12-06 at 11:35, Rod Taylor wrote: > On Fri, 2002-12-06 at 11:04, Tom Lane wrote: > > Joe, have you heard of a standard called SQL/MED? I came across a > > It's that one of the later parts of the SQL 99 spec? Section 9 or > thereabouts? Note to self, don't reply to emails and have a separate conversation at the same time. Found SQL/MED, Section 21 of ISO 9075-9. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] SQL/MED spec for cross-database linkages
On Fri, 2002-12-06 at 11:04, Tom Lane wrote: > Joe, have you heard of a standard called SQL/MED? I came across a It's that one of the later parts of the SQL 99 spec? Section 9 or thereabouts? -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
[HACKERS] SQL/MED spec for cross-database linkages
Joe, have you heard of a standard called SQL/MED? I came across a description of it the other day. You might think it's got some medical connotation, but actually the acronym is Management of External Data, and what it is is a standard spec for shipping chunks of SQL queries to remote servers. For instance, given SELECT * FROM a.foo, b.bar WHERE ... where a.foo is on a remote machine, the spec lays down how the local and remote servers can cooperate to execute this query intelligently --- including deciding where to execute various WHERE clauses to minimize the amount of data shipped. (The article I found was actually about how the new draft version of SQL/MED improves the protocol to let this sort of thing be done better; it seems the original spec only allowed retrieval of a whole table's contents.) This looks like it might be a great long-term replacement for dblink, and if it is standard, so much the better. I imagine the draft version of the new SQL/MED spec may be available on the web, but haven't gone looking. Just a heads-up in case you are interested... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4 Wishlist
Kevin Brown wrote: > How useful would it be? Beats me. Like I said, you could perform > some "what if" games with a database this way that you currently > can't, but I don't know how useful that would be. On thinking about > it a bit, it seems option 1 would be the most useful and perhaps the > most sensible. > > > Of course, perhaps the whole thing is just another stupid idea... We would need to have some people who want this first. We don't add stuff of questionable value because then the feature set becomes confusing to end users. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] new interface
On Fri, 2002-12-06 at 10:30, Reggie Burnett wrote: > Let me see if I can add more information here. PSQL appears to only > retrieve table metadata when \d is given. For my interface, I will need > the ability to present every column as a proper system object (int, byte > array, currency, etc) depending on the db type. I will not be able to > wait for the user of my interface to execute a method before retrieving > this data so I will need to automatically retrieve it every time. > Having looked at the query issued by \d in PSQL, it would seem that I > would need to issue that same query for every column in my select. I > say that because it contains a join of pg_class and pg_attribute. Something like that I would suspect. But if they're arbitrary selects, how are you going to handle: SELECT CAST(32 AS text); -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] new interface
Let me see if I can add more information here. PSQL appears to only retrieve table metadata when \d is given. For my interface, I will need the ability to present every column as a proper system object (int, byte array, currency, etc) depending on the db type. I will not be able to wait for the user of my interface to execute a method before retrieving this data so I will need to automatically retrieve it every time. Having looked at the query issued by \d in PSQL, it would seem that I would need to issue that same query for every column in my select. I say that because it contains a join of pg_class and pg_attribute. Am I understanding this right? > -Original Message- > From: Rod Taylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 06, 2002 9:19 AM > To: Reggie Burnett > Cc: PostgreSQL-development > Subject: Re: [HACKERS] new interface > > On Fri, 2002-12-06 at 09:55, Reggie Burnett wrote: > > I'm working on a new interface to PostgreSQL and having a difficult > > time. Perhaps someone here can shed some light on the subject. > > > > 1. Am I correct in thinking that the OID that I receive with the > > RowDescription is the column type? I have several of those defined from > > The OID is just a relatively unique database wide row marker -- which > you cannot count on existing in user tables. Nothing more or less. In > some of the system tables it is used as a foreign key to records in > other system tables, but Oid by itself has no such meaning. > > > > > I have read through all the docs/faqs I can find and still have no good > > idea about this. > > Take a look at the 'System Catalog' documentation, and in psql the -E > option will show you the 'system' queries used to retrieve the > information for display in psql. > > -- > Rod Taylor <[EMAIL PROTECTED]> > > PGP Key: http://www.rbt.ca/rbtpub.asc ---(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] new interface
> -Original Message- > From: Rod Taylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 06, 2002 9:19 AM > To: Reggie Burnett > Cc: PostgreSQL-development > Subject: Re: [HACKERS] new interface > > On Fri, 2002-12-06 at 09:55, Reggie Burnett wrote: > > I'm working on a new interface to PostgreSQL and having a difficult > > time. Perhaps someone here can shed some light on the subject. > > > > 1. Am I correct in thinking that the OID that I receive with the > > RowDescription is the column type? I have several of those defined from > > The OID is just a relatively unique database wide row marker -- which > you cannot count on existing in user tables. Nothing more or less. In > some of the system tables it is used as a foreign key to records in > other system tables, but Oid by itself has no such meaning. So if OID can't be counted on to be there 100% of the time, what do I use to index the catalog to determine type, not null-ness, uniqueness, etc? > > > > > I have read through all the docs/faqs I can find and still have no good > > idea about this. > > Take a look at the 'System Catalog' documentation, and in psql the -E > option will show you the 'system' queries used to retrieve the > information for display in psql. > > -- > Rod Taylor <[EMAIL PROTECTED]> > > PGP Key: http://www.rbt.ca/rbtpub.asc ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] new interface
On Fri, 2002-12-06 at 09:55, Reggie Burnett wrote: > I'm working on a new interface to PostgreSQL and having a difficult > time. Perhaps someone here can shed some light on the subject. > > 1. Am I correct in thinking that the OID that I receive with the > RowDescription is the column type? I have several of those defined from The OID is just a relatively unique database wide row marker -- which you cannot count on existing in user tables. Nothing more or less. In some of the system tables it is used as a foreign key to records in other system tables, but Oid by itself has no such meaning. > > I have read through all the docs/faqs I can find and still have no good > idea about this. Take a look at the 'System Catalog' documentation, and in psql the -E option will show you the 'system' queries used to retrieve the information for display in psql. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Postmaster windows shell
- Original Message - From: Igor Georgiev To: mlw Sent: Friday, December 06, 2002 4:57 PM Subject: Re: Postmaster windows shell - Original Message - From: "mlw" <[EMAIL PROTECTED]> To: "Igor Georgiev" <[EMAIL PROTECTED]> Sent: Friday, December 06, 2002 3:43 PM Subject: Re: Postmaster windows shell > Yea, send it.> > Is it GPL? I just receive approval from gborg. This project is released under the Mozilla Public License (MPL). http://gborg.postgresql.org/project/winmaster/projdisplay.php but with my zero expirience with cvs i dont upload nothing yet :((( any help be welcome :) here is raw source with Dev-C++ project > Does it compile under cygwin or MSC?> (I have both)> mingw, but i thin it will run wtoh -mno-cygwin
[HACKERS] new interface
I'm working on a new interface to PostgreSQL and having a difficult time. Perhaps someone here can shed some light on the subject. 1. Am I correct in thinking that the OID that I receive with the RowDescription is the column type? I have several of those defined from the 7.3 source code. Have those changed in the past and are they likely to change in the future? I have heard people talking about querying the server for type names or type oid values but I can't believe it is that difficult. 2. How do I receive the column modifers such as not null, primary key, indexed, etc. I know RowDescription sends down type modifiers but on an int4 column that field is always -1. I use another client app to change the column from allowing nulls to not allowing nulls (same value in column). The client app as well as psql on Linux sees the change but my interface still receives just -1 for the type modifier. What am I missing? I have read through all the docs/faqs I can find and still have no good idea about this. If there is someplace that has the oids documented or the low-level constants documented, I would love to see that. Thanks Reggie ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] big text field -> message type 0x44
Tom Lane writes: > Lee Kindness <[EMAIL PROTECTED]> writes: > > Tom Lane writes: > >>> Okay, so it seems -D_REENTRANT is the appropriate fix. > > However, _REENTRANT is not a Solarisism... On all (recent) UNIX > > systems it toggles on correct handling for thread specific instances > > of historically global variables (eg errno). It should be considered > > for all platforms if libpq is intended to be used from threaded > > programs. > Now that I think about it, what that macro is probably really doing is > switching the code from looking at a static "errno" variable to looking > at a per-thread variable. So in fact -D_REENTRANT would be correct if > you intended to link with a thread-aware libc, and wrong if you intended > to link with a non-aware libc. (Is there such a thing as a non-threaded > implementation of libc on the platforms where -D_REENTRANT does > anything?) If this analysis is right then I think we should *not* > force _REENTRANT; it will have to be up to users to choose the mechanism > they want to use in their programs. I think in the long-term the libraries are going to have to be looked at in detail to ensure they work as would be expected from multithreaded programs. I cannot see any harm in adding -D_REENTRANT to CFLAGS even though some platforms supersede it with -lthread or something (becaue they still define _REENTRANT behind the scenes). I remember in the past reading in detail the issues involved with making shared libraries work as expected from threads. However I no-longer has access to that book, but think it was "Multithreaded Programming with Pthreads"... Again, something i'd like to look at later this month. Workwise the threaded code we had which used embedded SQL calls in C fell into heaps when moved from Ingres to PostgreSQL. And Ingres's ESQL/C is real crap for threading and we employeed loads of mutexes... So, ... Lee. ---(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.4 Wishlist
Tom Lane wrote: > "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes: > > Mysql is planning on making this work: > > SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id. > > We're supposed to spend our time emulating nonstandard features that > don't even exist yet? I think I have better things to do ... MySQL doesn't have it, but I believe MS SQL does (and thus Sybase probably does as well). I agree with others that variables would be quite handy, especially if they persist between statements (and they might be even handier if they persist between transactions). That's not to say that you don't have better things to work on, though. :-) -- Kevin Brown [EMAIL PROTECTED] This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ---(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] Postmaster windows shell
- Original Message - From: mlw To: Igor Georgiev Cc: [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 6:52 PM Subject: Re: Shrinkwrap Windows Product, any issues? Anyone? (postmaster windows shell) Hey this is a cool project. I have been thinking doing the exact ame thing, the console Window of 2K/XP just kills the daemon, yuck.What can I do to help? - Original Message - From: "Justin Clift" <[EMAIL PROTECTED]> To: "Igor Georgiev" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 05, 2002 11:32 PM Subject: Re: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone? (postmaster windows shell) Hi Igor, This would be a really good thing to get into GBorg as a project, so people could work on this through CVS. Would you like to register it as a project? Mark, do you feel it would be better to put your installer plus this together into one project on GBorg too? Not sure, it's just a thought. Was [Re: Shrinkwrap Windows Product, any issues? Anyone? (postmaster windows shell)] Justin : Current active projects: Project Role winmaster (awaiting approval) Admin WinMaster - windows console for PostgreSQL mlw: > I am working on a HOWTO, a set of Windows batch files, and the install > scripts I would be glad to post, and I would be very glad to include > Igor's console in the install.> > It would make a cool offering. Its Ok 4 me. Unfortunately i havent Windows 2K/XP so i can't test it :(. I can send u source if u wish.
Re: [HACKERS] 7.4 Wishlist
Bruce Momjian wrote: > Kevin Brown wrote: > > I'd also like to see (if this is even possible) a transaction > > isolation mode that would make it possible for multiple concurrent > > updates to the same row to happen without blocking each other (I > > imagine one way to make this possible would be for the last > > transaction to commit to be the one that "wins". Each transaction > > that commits gets its updates written so that other transactions that > > begin after they commit will see them, of course). Neither "read > > committed" nor "serialized" modes offer this. Don't know if it's > > possible, but it would be nice (such that a transaction sees the > > database as if it has it all to itself and doesn't block on > > updates)... > > How would you do the update if you don't know of the transaction commits > or aborts? Maybe I should explain what I'm thinking a little further. What I'm proposing is a transaction isolation model where each transaction thinks that it's the only one making changes to the database. That assumption obviously fails *outside* of a transaction, but inside a transaction it should be possible to maintain the illusion. We already get this with serialized transaction isolation mode, with one caveat: when an update conflicts with that of another transaction that committed while the transaction of interest is in progress, the transaction of interest gets rolled back immediately with a serialization error. What I'm proposing is to extend the illusion to updates. A transaction running in this new isolation mode (call it "full isolation" or something) never sees updates that other committed transactions perform, whether they would conflict or not. The view the running transaction sees of the database is a snapshot in time, as it were, plus any updates the transaction itself has made. Now, there are a couple of approaches we can take at transaction commit that I can think of right now: 1. If there were any serialization errors, abort the transaction at commit time. This allows transactions to safely make changes to their local view of the database without compromising serialization. This probably wouldn't yield any benefits over the serializable isolation level except that it would make it possible to perform experiments on a database that currently can't be performed (since serializable isolation aborts the transaction at the first serialization error). Applications would be easier to write since there would be only one point during a transaction that the application would have to check for unexpected errors: the commit. 2. We commit the changed rows. Updates only happen to rows that exist at commit time. Rows which the transaction deleted and which still exist at commit time are deleted. Referential integrity rules are enforced, of course, so it's possible for the database to retain some of its sanity even in the face of this model. But the overall state of the database will probably be unpredictable (in this scenario, the last concurrent transaction to commit "wins", more or less). 3. We do something more sophisticated than 1 or 2. Perhaps something analogous to the branch merge functions that CVS and other concurrent version control systems can perform, where multiple branches are finally merged into a single unified source snapshot. I have no idea how this would work for real, or if it's even possible (I believe CVS requires manual intervention to resolve branch conflicts during a merge, an option that would obviously not be available to us). How useful would it be? Beats me. Like I said, you could perform some "what if" games with a database this way that you currently can't, but I don't know how useful that would be. On thinking about it a bit, it seems option 1 would be the most useful and perhaps the most sensible. Of course, perhaps the whole thing is just another stupid idea... ---(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] [GENERAL] PostgreSQL Global Development Group
> -Original Message- > From: Josh Berkus [mailto:[EMAIL PROTECTED]] > Sent: 05 December 2002 23:37 > To: [EMAIL PROTECTED] > Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group > > > BTW, we do coordinate with the Website development group When did that happen then? I think I must have blinked :-) Regards, Dave. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
