Re: [HACKERS] v7.4 Bundled ... please test ...
On Tue, 5 Aug 2003, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Please test and let me know if there are any problems ... The .gz tarball matches what I have here. Didn't check the .bz2 one. All the .bz2 one is is 'gunzip *.gz;bzip2 *.tar', so should be good :) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Building beta packaging fails ...
'k, removed and trying build again ... On Tue, 5 Aug 2003, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: GNUMakefile.in: opt_files := \ src/tools src/corba src/data src/tutorial \ Ah. I take it then, that src/data shoudl be removed from there too? Yep. Sorry I missed it. regards, tom lane Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Building beta packaging fails ...
Using the attached script, the build fails while trying ot tar up the distributions ... when its trying to build the tools tar file, error being that it can't find the src/data directory ... compared against the snapshot build script, it doesn't look like I've missed anything, and i haven't changed the build script fo rbeta recently, other then the v7.4 stuff ... Makefile problem, or a directory that is supposed to be built? #! /bin/sh set -e export PATH=/usr/local/bin:/usr/bin:/bin:/sbin cd /usr/local/pgsql/beta if [ -d pgsql ] then mv pgsql pgsql.dead fi if [ -d pgsql.dead ] then rm -rf pgsql.dead fi /usr/bin/cvs -d /cvsroot -q checkout -rREL7_4_BETA1 -P pgsql /usr/bin/find pgsql -type d -name CVS -print | xargs rm -rf cd pgsql ./configure cd doc/src gmake postgres.tar.gz mv postgres.tar.gz .. cp /var/spool/ftp/pub/dev/doc/man.tar.gz .. cd ../.. gmake split-dist=yes dist gmake maintainer-clean for x in *.tar.gz; do md5 $x $x.md5 done mv *.tar.gz *.tar.gz.md5 /var/spool/ftp/pub/source/v7.4 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Farewell
I never know what to say in response to stuff like this ... its like having to sign a card when a co-worker leaves ... then again, unlike most co-workesr, I can definitely say its been a great pleasure to have known, and worked, with you ... you brought, and gave, alot to the project, and for that, we thank you ... thanks :) On Sun, 10 Aug 2003, Vadim Mikheev wrote: FarewellIt's time for formal acknowledgement that I'm not in The Project any more. I'm not interested in small features/fixes and have no time for big ones. It was this way for very long time and I don't see how/when that could change. My participation in The Project was one of the greatest adventures in my life. Thanks to everyone! Good luck on your ways. And - long live to Postgres!!! Vadim Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] When did we get to be so fast?
On Thu, 7 Aug 2003, Bruce Momjian wrote: Man, I can't do anything right; should be: one INSERT per transaction, fsync true 934 one INSERT per transaction, fsync false 1818 INSERTs all in one transaction, fsync true 4166 Brain thinking one thing, fingers typing something totallydifferent, eh? :) ---(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] Just ignore ... just a test
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] When did we get to be so fast?
On Thu, 7 Aug 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I was just testing the threaded ecpg, and ran some performance tests. Without using threads, I am seeing 100,000 inserts of a single word into a simple table take 12 seconds: CREATE TABLE test_thread(message TEXT); giving me 8333 inserts per second. That seems very high. Single transaction, or one transaction per INSERT? This is ecpg, and I didn't have AUTOCOMMIT on, so it was a single transaction. I had forgotten that. Also, I was wrong in my computations. It is 4166 inserts per second, not 8333. Sorry. I am now seeing more reasonable numbers: one INSERT per transaction, fsync true 934 one INSERT per transaction, fsync false 1818 one INSERT per transaction, fsync true 4166 Shouldn't 1 and 3 be about the same though? If both are 'one INSERT per transaction with fsync true', how come such a massive difference in #s? ---(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] v7.4 Bundled ... please test ...
'K ... I just re-tag'd REL7_4_BETA1 for the changes that were made (including Bruce's last minute copyright changes) ... Also, I just modified the script so that it builds both a .gz and a .bz2 version of hte archives ... Please test and let me know if there are any problems ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Building beta packaging fails ...
GNUMakefile.in: opt_files := \ src/tools src/corba src/data src/tutorial \ src/bin/pgtclsh \ $(addprefix src/interfaces/, libpgtcl jdbc) \ $(addprefix src/pl/, plperl plpython tcl) I take it then, that src/data shoudl be removed from there too? On Mon, 4 Aug 2003, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Using the attached script, the build fails while trying ot tar up the distributions ... when its trying to build the tools tar file, error being that it can't find the src/data directory ... Why is it looking for src/data? I removed all the files in that directory last night as part of the --enable-recode deletion. regards, tom lane Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Upcoming Release of PostgreSQL, Inc's erserver v1.2 ...
We (PostgreSQL, Inc) are just in the process of tying up some loose ends on eRServer v1.2, to be released OSS on GBorg over the next week or so ... since this is meant to replace rserv, I'd like to remove rserv from the v7.4 source tree ... As far as I know, the only patch made to rserv in the distribution was to extend it to do multi-slave, which eRServer v1.2 already does, *but* eRServer re-wrote rserv in Java, vs perl as it was originally ... Is there anyone actually using rserv who would be adverse to my removing it from the source tar ball? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] developer.postgresql.org is broken
already fixed On Mon, 28 Jul 2003, Christopher Kings-Lynne wrote: It's showing the apache page. Chris ---(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 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.3.4 bundled ...
On Fri, 25 Jul 2003, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: 'K, fixed the TAG to point to the right revision and am rebuilding the packages right now ... Repackaged tarball looks good from here. Don't forget to adjust the symlink at the top level of the FTP site ... Will do that up tonight and announce to the general lists ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] v7.3.4 bundled ...
Please check it over before I announce it more generally ... but she looks good from here .. Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(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] v7.3.4 bundled ...
'K, fixed the TAG to point to the right revision and am rebuilding the packages right now ... On Thu, 24 Jul 2003, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Please check it over before I announce it more generally ... but she looks good from here .. Almost there: src/backend/utils/adt/date.c is one rev behind where it should be. Looks like you checked out before I applied that fix from Joe Conway. regards, tom lane Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs problem
try it now ... I think its a pathing problem with a cron entry ... just fixed that, so should be okay now ... On Wed, 23 Jul 2003, Patrick Welche wrote: cvs server: Updating src/bin/scripts/po cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server/src/bin/scripts/po' (/projects/cvsroot/pgsql-server/src/bin/scripts/po/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server/src/bin/scripts/po' cvs [server aborted]: read lock failed - giving up On a different note, I also wonder about: M src/backend/parser/gram.c It seems that you checkout the source with no gram.c. Build it, thus creating gram.c. Next time you cvs update, you get Attic/gram.c merged in :/ - or is my use of cvs incorrect? (cvs -z3 update -P -d) Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Criteria for contrib/ versus gborg?
Did I miss part of a thread here? :) On Tue, 22 Jul 2003, Josh Berkus wrote: Andrew, Arguments? None of those three address the obvious marketing benefit of having replication shipping with the main tarball, I know. Those are pretty strong arguments ... and we can't let PostgreSQL new marketing awareness sway us to the point that we start making technically unfeasable decisions. So, I'm backing down ... I think despite the PR argument in favor of including eRServer as a download is seriously outweighed by Andrew's technical argument. So that we can get some PR milage out of it though, can we make sure that eRServer gets posted to GBorg about the same day as the 7.4 release? That way we can at least include eRServer in our announcement. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] anoncvs problems.
check it now, should be fine ... On Mon, 21 Jul 2003, Kurt Roeckx wrote: When doing cvs update I get: cvs server: Updating contrib/tsearch2 cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server/contrib/tsearch2' (/projects/cvsroot/pgsql-server/contrib/tsearch2/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server/contrib/tsearch2' cvs [server aborted]: read lock failed - giving up Kurt ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patches List
Got stuck with: A MIME header is too long (353 128) going through postings now ... On Wed, 16 Jul 2003, Larry Rosenman wrote: Yes I am subscribed. I also sent it to you directly seeing as if it was slow. LER --On Wednesday, July 16, 2003 17:16:55 -0400 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: Is the patches list working? I saw something come through yesterday from Rod. I submitted on yesterday that never made it. Are you subscribed? With Marc out of town this week, anything held for moderator approval won't see the light of day before Monday or so... 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 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Archives
On Wed, 16 Jul 2003, Alvaro Herrera wrote: On Wed, Jul 16, 2003 at 01:57:41PM -0500, Thomas Swan wrote: Does anyone have recent archives of the pgsql-hackers list in mbx or flat file format? I know that I can search through the website or through other interfaces, but I would like to be able to download a file containing the posts for a period of time. I really miss this too. I searched the entire site, including Majordomo's web interface, and there is no way to get the mbox archives. It seems the only way to get'em is buying them from Pgsql Inc. Remind me in a week if I haven't fixed that already ... hadn't even realized it wasn't there anymore, and this is the first I've seen someone mention it ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] commiters log
posted and shouldn't be delay'd in the future ... On Fri, 18 Jul 2003, Tom Lane wrote: Oleg Bartunov [EMAIL PROTECTED] writes: today we've commited bug fix in ltree code to current CVS, but I don't see any notices in COMMITERS mailing list. Do we need to so something special ? Check with Marc when he gets back from vacation. He probably forgot to give you some permission or other. I recall that everybody's commit posts were delayed by permissions problems right after the big server crash awhile back... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(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] How to submit Tsearch V2 ?
On Thu, 3 Jul 2003, Oleg Bartunov wrote: Marc, we hope to get an access to be able submit patches. I sent back a note to Teodor earlier this evening letting him know that I think I got the password issue fixed with CVS, but asked him to test and get back to me ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Sat, 28 Jun 2003, Jan Wieck wrote: Bruce Momjian wrote: See my recent commit of src/tools/pgtest. It might be a good start. I was wondering if some existing framework, like from the Apache Xalan package, would be a better point to start from? I hate to say it, Bruce, but you try to reinvent the wheel by starting with a sled. Hey, I take offence at that ... up here in Canada, that sled is faster, dontcha know? especially if we throw those dogs in front of them :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
On Thu, 26 Jun 2003, Thomas Swan wrote: Of course, these are just ideas and I'm not sure how practical it is to do any of them. I just am really concerned about the uninstall/clean up phase and how that can be done in an orderly fashion. Unless the process can start from a clean state again, then it won't be valid. At one point I had even given thought, vainly, to purchasing VMWare for such an occasion. Suggestions? Personally ... if you could build up the test script, I think there are enough ppl with more platforms on these lists that would be willing ot run it ... the problem isn't getting the farm together, its coming up with the automated (or even semi-automated) tests :( ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Thu, 26 Jun 2003, Rod Taylor wrote: I think we should replace Bruce's pgtest script with this one -- with an argument to accept the email address to report to for FAILING cases. Success isn't very interesting if it runs regularly. that was why I suggested getting it into the tree ... to at least give a starting point to work from ... and I have at least one machine right now that I can run such tests on ... Dual PII with FreeBSD 5.x-CURRENT on her ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
On Thu, 26 Jun 2003, Kevin Brown wrote: It doesn't sound like a bad idea ... but, it pretty much comes down to the original thread: are you willing to step up and maintain such a project? Yes, I am (how hard can it be?, he asks himself, knowing all the while that it's a really bad idea to be asking that question. :-). But I haven't the faintest idea of how or where to even start, so pointers would be appreciated. Which, of course, is always the fun part ... I believe Thomas is going to be starting to work on test scripts, so you might want to co-ordinate with him ... ---(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] RServ patch to support multiple slaves (sorta)
On Wed, 25 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. Considering how many ppl have commented in the past how rserv was broken anyway ... ? I'd say it can't hurt anything ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature freeze and the great elog changeover
On Wed, 25 Jun 2003, Tom Lane wrote: I had originally planned to spend the next week editing all the elog() calls in the backend to convert them to ereport() format where helpful, add SQLSTATE values, and update wording to match the style guidelines that were agreed to awhile back. However, it looks like the same reasons that were holding me back still apply: any wholesale editing will likely break unapplied patches, plus I'll have to go back through the code when those patches do get applied. With folk scrambling to get last-minute stuff done before feature freeze, these are not good side-effects. What I'd like to do instead is try to get the editing done during the interval between feature freeze and the start of beta (which we've already agreed is July 1 - July 15). I do not feel that this violates the spirit of feature freeze, but does anyone want to object to that plan? Based on the reasons given, it sounds like it would be more harmful not to do it when things are supposed to be frozen ... no objections here ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
On Wed, 25 Jun 2003, Shridhar Daithankar wrote: On 25 Jun 2003 at 14:50, Andreas Pflug wrote: Jan Wieck wrote: Change that into * Remove bugs from source code and get a patent on it. Should be a nobrainer (as in those guy's have no brains) considering that NetFlix even got a patent on DVD subscription rentals: http://slashdot.org/article.pl?sid=03/06/24/1458223mode=flattid=155tid=99 I'm applying for a patent on breathing now. The trick I found is reversing the direction of airflow in a regular way. The algorithm seems apparently simple, but it really makes the deal: Step 1. If your lungs are empty, let air flow into them through some air intake. This airflow might be ducted by some bronchial or additional tubing. Step 2 (optional) As soon as there's enough air in the lungs, you may decide to hold it there for a while. Some time limits might apply, please consult some specialist for details. Step 3 Press the air out of the lungs, using some muscles or externally applied force on the chest. The air will eventually escape through some body opening. Another patent I'll be applying for covers the use of nostrils for this purpose. Step 4 Restart the cycle at step 1. Regards and don't dare to try this without royalty fees! Oops... I challenge it for prior art..:-) Why, are you older then he is? I think that is about the only way that 'prior art' would apply here, no? :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Wed, 25 Jun 2003, Kevin Brown wrote: So...would it make sense to create a gborg project to which people who have written their own test suites can contribute whatever code and data they feel comfortable releasing? As a gborg project, it would be separate from the main PG distribution and would thus have no impact on the build process or anything like that. But at the same time, if there are any ideas on testing that people have had, they could be shared with others through that mechanism. And any tests which prove to be particularly useful could make their way into the PG distribution if people here wish. Of course, like anything else this could be a bad (or perhaps redundant) idea. :-) It doesn't sound like a bad idea ... but, it pretty much comes down to the original thread: are you willing to step up and maintain such a project? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
On Wed, 25 Jun 2003, Alvaro Herrera wrote: Are you saying that it doesn't matter that it is made more broken? Sorry if I disagree... we should be trying to fix it, not the other way around. If it's so broken, why hasn't it received any improvement? Is there some problem with the underlying design? I suppose the erServer code is at least vaguely based on this, right? eRServer is to rserv, at this stage, like night is to day ... eRServer is a single master, multislave replication re-written completely in java to make use of the threaded/parallel nature of java to eliminate the deadlocks, and backlogs, that single-threaded presents ... In fact, the *current* eRServer (which we're currently working on the documentation for, and will be shipping out soon) now does multi-database to multi-slave without having to start up several erserver processes, where before you had to do one server per database ... ---(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] Two weeks to feature freeze
'K, and do you have any ETA on when you'll have this translated into some useful tests that we can incorporate? On Mon, 23 Jun 2003, Dann Corbit wrote: Here is a list of a small sample of the citations available from the ACM on software testing: http://portal.acm.org/citation.cfm?id=581358coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=376180coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=367020coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=308790coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=257668coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=248262coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 http://portal.acm.org/citation.cfm?id=227759coll=portaldl=ACMCFID=657 0092CFTOKEN=81653602 These articles are careful, scientific studies that have been extensively peer reviewed. These articles indicate that testing is a good idea. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(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] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: -Original Message- From: Jan Wieck [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2003 10:30 PM To: Dann Corbit Cc: scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development Subject: Re: [HACKERS] Two weeks to feature freeze [snip] I personally think you don't actually ever did any software testing yourself. You are not really talking from experience, are you? So please, show me what you have now, or get one more plus on my minus-list. I have already posted enough information to show my qualitications. Whether I am qualified or not is irrelevant to whether the argument has merit or not. I have raised what I consider to be an important issue. You have raised a point that you are not prepared to do anything about though ... nobody disagrees with you about adding more testing, but if you aren't willing to do the work, why should anyone else be? Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: Would it be nice if we had more tests? Yes. In fact, one of the items on my personal todo list is to devise a more versatile performance test than pgbench for testing postgresql parameters, builds, and installations. But it's not getting done by me carping at people on the Hackers list. It'll get done when I spend a long weekend writing Perl. Put up or shut up time, Dann. It's shut up, then. I'm not willing to commit to this effort. Woo hoo ... now *that* was the longest, useless thread I think we've had here so far .. we almost need to start a 'hall of shameful threads' ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Robert Treat wrote: On Mon, 2003-06-23 at 21:36, The Hermit Hacker wrote: On Mon, 23 Jun 2003, Robert Treat wrote: The target-date-based approach we've taken in the last couple of releases seems much more productive. productive on a small scale; for sure. productive for large scale features... well, that's why it's being discussed. 'K, but if we extend the dev cycle in order to get 'foo' in, how is that better then having 'foo' continue to be developed thru the release and committed in the next cycle? I think it makes it easier to code 'foo' since you're not coding against (quite as much of) a moving target. I *soo* disagree with this one ... the only way that postgresql is going to stop being a moving target so that someone can code 'foo' is if everyone else goes to sleep until that happens ... It could also help people plan better since they would know that foo is coming in the next release. 'K, that helps the end users, but that doesn't do anything for the person developing 'foo' ... i'm sure everyone who doesn't want foo would agree with that position. The counter though is those folks who did want foo but now have to wait 4-6 months for the next release since foo took a month longer to develop than was initially planned. Ya, but, based on past experience (hell, this release has been a good example) ... you delay the release because developer of 'foo' figures oh, it will be ready in another month, and then something comes up that causes that commitment not to happen, so we delay it yet another month? And I'm not saying that the second delay was due to mis-estimating the time needed ... suddenly getting really busy on a contract, a day job, a death in the family, etc ... you cannot predict what could cause a delay, or how long such a delay would take ... the whole discussion is based on how do we get big projects done when no one is motivated to work on 'foo' until there faced with a deadline; this idea puts the pressure on 'foo' developers from the get go. i'm not saying this a guaranteed way to solve that problem but i think it is a possible solution. i'm sure there will be big projects most people don't care about (win32) and big projects most people would like (replication) so the amount of like or dislike of the idea would be relative in practice, the key question is would this actually motivate folks more to get big projects finished faster? since there are only a handful of folks who fall into that category they can decide for themselves, and if it wouldn't motivate them, then the question can be asked again, what would? First, we already seen that such a 'pressure' doesn't matter, especially if when push comes to shove, they know we'll postpone to accommodate them ... Second ... I don't believe the problem *is* the release cycles ... I think the problem that needs a solution is how to open up these large projects so that the deadline(s) don't fall on ones person's shoulders to get done .. how do we encourage/promote work groups for the large projects? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list Someone has to spearhead it ... you seem to be passionate about seeing it happen, but don't care enough to do anything about it ... Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? ---(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] Two weeks to feature freeze
On Tue, 24 Jun 2003, Bruce Momjian wrote: The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) 'K, can you add that one too? :) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Dann Corbit wrote: Don't care and won't do are not the same thing. Well, actually, they are ... if someone doesn't care, they aren't going to do, are they? You have had the time to do everything you ever cared about? No no, that isn't what he is arguing (or I'm miss reading) ... he said that not caring about something *and* not doing it aren't the same thing ... which isnt' the same as caring but not having the time ... is it? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] PHP/PgSQL *and* libpq ...
Just a side bar to the whole thread about PHP/MySQL ... I realize that libpq is intwined with the backend right now, but if anyone could think of a way of at least adding a make target that would create a libpq.tar.gz distribution, I believe it would go a long way towards making it easier for ppl to add/compile in PgSQL support into PHP ... right now, to do so, you have to download an 8Meg file to get libpq ... if it could be reduced to a .5Meg tar.gz file: svr1# du -sk libpq 532 libpq it would be less onerous to download and add the support in ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] libpgtcl and pgtclsh
I'm looking to move both of these over to GBorg, like we did with the C++ interfaces and ODBC ... the problem is, unlike those, I can't find anyone that is actually working with it ... Is anyone using these? Anyone willing to step up and act as maintainer for it? Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Jan Wieck wrote: The Hermit Hacker wrote: On Tue, 24 Jun 2003, Bruce Momjian wrote: The Hermit Hacker wrote: On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) 'K, can you add that one too? :) Make his life easier: Replace the entire TODO with Make PostgreSQL better That pretty much summs it up, no? Oh, I like that ... definitely leaves it open to the interpretation of the reader as to what would make it better :) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] informatoin reagarding the last date of submission
On Mon, 23 Jun 2003, Srikanth M wrote: Hi! Can anyone give me the informatoin reagarding the last date of submission of the code to be added in next version of pgsql. June 30th ... ---(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] Two Phase Commit WAS: Re: Two weeks to feature freeze
I second the agreement ... a 'reference implementation', of sorts, at least gives someone to build on then starting right from scratch ... On Mon, 23 Jun 2003, Bruce Momjian wrote: Agreed. --- Josh Berkus wrote: Tom, No. I want to know what the subordinate does when it's promised to commit and the co-ordinator never responds. AFAICS the subordinate is screwed --- it can't commit, and it can't abort, and it can't expect to make progress indefinitely on other work while it's holding locks for the not-quite-committed transaction. AFAIK, MS SQL Server's two-phase commit works like this ... if both servers prepare, and one crashes, the transaction is screwed up. Somewhat unreliable considering the frequence with which MSSQL crashes, yet it seems to be good enough for several companies to sell solutions based on it. (performance is also appalling, but that's a different issue) Anybody have a grasp of Oracle internals for 2PC? Anyway, I would vote for a first implemenation for 2PC which addressed the commit-then-crash issue in some expedient-but-not-reliable way, and putting 2PC in /contrib with a not for production use warning. Some people will use it in production anyway, and hopefully one or more of them will put in the dozens of hours required to make it reliable. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ftp mirror
Sorry about that, I had long ago fixed the build, but failed to add it to cron ... new build created and cron entry added ... :( On Mon, 23 Jun 2003, Tom Lane wrote: [EMAIL PROTECTED] writes: Is it me or is there a problem with ftp mirrors? The latest shapshots I have here are from June 2; seems rather old.. It's not the mirrors' fault --- the nightly snapshots aren't getting updated on the master site either. I think this is still on Marc's to fix list. With beta getting closer, I hope he fixes it soon... 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]) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Auto Building / Testing (was: Re: [HACKERS] Two weeks to feat..)
On Mon, 23 Jun 2003, Peter Eisentraut wrote: Bruce Momjian writes: Well, it is a nice test template for people who aren't shell script experts, and I have been in the habit of pushing stuff I use into /tools so it is available for others. I know and I'm not happy about it. The PostgreSQL source tree isn't a repository of everyone's favorite shell scripts. There's an official method to build and test a PostgreSQL installation. If that is flawed or incomplete, then let's talk about it. But everyone pushing out their own little test methodology without further consideration is not going to help this discussion. 'K, its flawed and incomplete, let's talk about it :) What I was looking for here was something I could add to cron on a machine that would update the source, do a base configure (or give me the ability to give extra options, as the case may be), build, install and test, and report errors to me via email where applicable ... The idea is that it could be something that ppl could have run nightly, in the wee hours, and only when a problem occurs would they be informed so taht they coudl either fix teh error (ie. out of space), or report it to the list(s) ... ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Robert Treat wrote: The target-date-based approach we've taken in the last couple of releases seems much more productive. productive on a small scale; for sure. productive for large scale features... well, that's why it's being discussed. 'K, but if we extend the dev cycle in order to get 'foo' in, how is that better then having 'foo' continue to be developed thru the release and committed in the next cycle? If it takes foo 6 months to develop, I'd rather have the release happen after 4 months as per normal (or close to it) and have 'foo' brought in part way into dev cycle 2 ... at least then, if 'foo' ends up taking 7 months, we aren't delaying even further ... Its not like our dev cycles have 'idle periods' where nothing is happening and we're waiting for a feature to come along ... there is *alot* of changes going on that affect alot of ppl that don't really care about feature 'foo' coming along ... ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Dann Corbit wrote: The resistance to testing is typical of programmers. The PostgreSQL group is a group of programmers. I don't think I can change anyone's mind, since the most significant people on the list don't think it is worth the bother. Therefore, I am going to stop harping on it. *rofl* I believe several of us have suggested that we would welcome submissions for improved testing ... so, what, we feel that the test that is done is sufficient, but are willing to accept submissions to improve it, but you aren't willing to spend the time/effort to do so? We might be a bunch of 'typical programmers', but you definitely sound like a typical I want you to do something to make life easier for me, but am not willing to expend the time or effort to do anyting about it ... ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Sun, 22 Jun 2003, Bruce Momjian wrote: Mike Mascari wrote: I was disappointed that Satoshi Nagayasu's two-phase commit patches seemed to be implicitly rejected by lack of an enthusiastic response by any of the core members. Distributed query (not replication) would have been a very nice feature. It's what separates, in part, Oracle Enterprise Edition from the Standard Edition, and it appeared someone (Satoshi Nagayasu) was more than willing to get the ball rolling. But the flight path bothered some I guess so we got nothin' I sure want two-phase commit. I don't remember it as being rejected, and we certainly need it, independent of replication. I don't recall the patch itself :( Mike, do you recall the date(s) for this? Reasons for rejections? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Sat, 21 Jun 2003, Bruce Momjian wrote: That's a tough call. I do worry about readability. We have made Win32 changes, and they aren't ifdefs, and we still have a running system, and I think we can do that for PITR too. I think the big issue, which may be your point, is to get incremental work into CVS as soon as possible so we continue to take small steps. Exactly ... its gotten to the point that the changes needed are large, so ppl are waiting until its all finished before submitting it ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
On Fri, 20 Jun 2003, Dann Corbit wrote: Designing tests is busywork. Desiging tests is boring. Nobody wants to design tests, let alone interpret the results and define correct baselines. But testing is very, very important. But we do do testing ... we even design testing (in the form of the regression tests) ... we just don't do testing that you personally approve of ... and, from what I've seen so far, you aren't willing to actually put *your* time where your mouth is ... design some tests and submit them to us ... if they are valid, they will get used ... If you feel that crash-me is a valid starting point, start there and see where it takes you ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
On Sat, 21 Jun 2003, Dann Corbit wrote: It seems pretty clear that there are warts on the Crashme test. Perhaps 70% or so is truly useful. Maybe the useful subset could be approximated or modified to be useful as a general tool set. And we all wait with baited breath for you to develop and submit such tests ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
On Sun, 22 Jun 2003, Jan Wieck wrote: The Hermit Hacker wrote: On Fri, 20 Jun 2003, Dann Corbit wrote: Designing tests is busywork. Desiging tests is boring. Nobody wants to design tests, let alone interpret the results and define correct baselines. But testing is very, very important. But we do do testing ... we even design testing (in the form of the regression tests) ... we just don't do testing that you personally approve of ... and, from what I've seen so far, you aren't willing to actually put *your* time where your mouth is ... design some tests and submit them to us ... if they are valid, they will get used ... If you feel that crash-me is a valid starting point, start there and see where it takes you ... Not that fast! I didn't take the time to check but it wouldn't surprise me if MySQL's crash-me is GPL'd and copyright MySQL AB. That's not an optimal point to start PostgreSQL test code from, is it? I didn't say to copy it, but if the format is what Dann feels is required to be taken seriously, it does give a starting point to work from ... the thing is, as I think it was Tom that pointed out, the crash-me is more a feature tester then anything ... but Dann appears to be stuck on it as the 'be all, end all of testing suites' ... ---(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] Two weeks to feature freeze
On Sun, 22 Jun 2003, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian writes: I have added a cleaned up version of this to CVS as src/tools/pgtest. This seems to be a platform-specific reimplementation of 'make clean; make check'. Why bother? Marc requested it. Is there anything platform-specific except the greps? Ya, the script looked like it did a bit more then just a 'make clean; make check' ... doesn't it? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Sun, 22 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I sure want two-phase commit. I don't remember it as being rejected, and we certainly need it, independent of replication. Is 2PC a real-world solution to any real-world problem? I have never seen a satisfactory explanation of what you do when you've reported that you're ready to commit and no confirmation ever comes back. Sooner or later you must violate the protocol in one direction or the other (ie, commit without confirmation or roll back in violation of your promise of being able to commit). I think it's a cool-sounding phrase that does not actually work in practice. I think 2PC can be used to build more complex features, like using dblink for cross-db modification queries. That was my understanding too ... as soon as you try and go distributed, you need some method of ensuring that the data is constant across them all ... ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Sun, 22 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I think it's a cool-sounding phrase that does not actually work in practice. I think 2PC can be used to build more complex features, Only if it works to begin with. If it's unreliable, what are you gonna build on it? The question was whether 2PC is useful. The question wasn't if an unreliable 2PC was useful. I have to back Bruce up on this one ... is there a reason why 2PC couldn't be made reliable? I'm guessin that Oracle supports 2PC ... ? If so, is it unreliable? ---(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] Two weeks to feature freeze
On Mon, 23 Jun 2003, Sailesh Krishnamurthy wrote: I'm not sure if I understand Tom's beef - I think he is concerned about what happens if a subordinate does not respond to a prepare message. I would assume that the co-ordinator would not let the commit go through until it has received confirmations from every subordinate. The application's commit will remain blocked against the co-ordinator when this takes place. Wouldn't 2PC have some sort of 'heartbeat' between the co-ordinator and subordinate? Like, if you had multiple subordinates and one crashed, the co-ordinator would have to know that and be able to continue on, no? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Mon, 23 Jun 2003, Christopher Kings-Lynne wrote: No. I want to know what the subordinate does when it's promised to commit and the co-ordinator never responds. AFAICS the subordinate is screwed --- it can't commit, and it can't abort, and it can't expect to make progress indefinitely on other work while it's holding locks for the not-quite-committed transaction. It takes itself offline and you need to resync it later?? Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the co-ordinator crashes? From the subordinates point of view, it has the complete transaction to commit, but the co-ordinator has gone down without telling it to do so ... ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Fri, 20 Jun 2003, Josh Berkus wrote: Ultimately, this is one of those technical vs. marketing questions ... whether to release now with a bunch of back-end features that the current users want, or to release later and include the features that we said were going to be in 7.4. And PostgreSQL is a technical project, not a marketing one. Technical or Marketing, I think ppl are putting too much emphasis on 'visible features' and not enough on the 'not so visible' ones ... improvements to both performance and footprint are massive changes, but they are more difficult to 'market', then, say, adding schemas was ... ---(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] Two weeks to feature freeze
On Fri, 20 Jun 2003, Tom Lane wrote: Time was that we had a major release every 3 or 4 months. As the project matures I think it's appropriate for the cycle to get slower: a lot of low-hanging fruit is gone, so we have larger jobs to tackle, plus users are using PG for larger databases and don't want to face major-version changes too often. But I don't want it to get to be a year on average between releases, at least not yet. 8 or 9 months seems reasonable, and by that standard we're overdue. Note that with how we've been releasing 'minors' on v7.3.x semi-regularly, slippage isn't *as* big an issue as it could have been ... ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Fri, 20 Jun 2003, Jason Earl wrote: Heck, there are probably more than 70 machines running CVS versions of PostgreSQL right this minute (Marc, any download numbers to back this up?). Unfortunately, most ppl testing would be using CVS or CVSup, which don't (or, at least, I haven't been able to find?) log such .. download wise, through the FTP site, maybe 20 downloads since the 4th of June of the snapshot ... ---(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] Two weeks to feature freeze
On Fri, 20 Jun 2003, Dann Corbit wrote: Hmm... I must have missed the huge corporation paying for in house testing of PostgreSQL. In the Free Software world the beta team is all of those people that need the new features so badly that they are willing to risk their own data and hardware testing it. I don't see how this model can possibly succeed then. You can't just hope that your end users will: 1. Exhaustively test 2. Accurately report the findings But it does, and has for 10 years now ... Our beta customers do help us to find bugs. Bugs reported by customers for released products are extremely rare. Check the past archives for the mailing lists ... our bugs reported by end users for released products is extremely rare also, and *generally* is a result of them doing something that nobody had thought to test for before ... Spoken like a programmer. Yes, real world data *always* turns up things that neither the testers nor the programmers imagined. But a huge and comprehensive conformance testing effort will turn up 99% of the problems. And ours do ... I don't believe I can recall us having a release where we've had a stream of problem reports come flying in afterwards ... we might get one or two from ppl that have hit a 'never before seen' bug, that generally gets fixed very quickly ... 100% code coverage is impossible. Program proving is impossible. 0% defect code delivery is impossible. But you should try to approach the ideal as closely as can be attained. And we do ... The tests are good tests. They cover a wide range of features and functions and discover if you can cause permanent damage to a database by simply performing end-user queries. The scripts are a bit hokey, but it isn't all that difficult to get them to run. Well, if you would like to volunteer to run them against PostgreSQL, and let us know what fails, we can let you know why said test is wrong in the first place ... we've been through crash-me several times before, and 'fixing crash-me' was more work then it was worth ... Basically any time a competitor differed from MySQL an error would be generated (despite the fact that it was very likely that it was MySQL that was wrong). This is unfair and untrue. (I have no connection whatsoever with the MySQL group, BTW). Been there, done that ... even tried to get changes made to make the tests more accurate ... it was like trying to move a mountain ... PostgreSQL has an excellent programming team. Why not try to recruit a similar testing team? I think it would strongly differentiate the tool set from similar free stuff. Are you volunteering? We already have a testing team we're happy with, but if you would like to extend it with your resources, please feel free to join in ... ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Two weeks to feature freeze
On Sat, 21 Jun 2003, Bruce Momjian wrote: What does bother me is that we weren't getting any closer on those _hard_ items. At least with this release, we will be _closer_ on Win32 and PITR. Maybe our problem is such a ... hatred of #ifdef? Maybe its time to go back a bit to our roots ... get the 'experimental features' in with #ifdef so that others have a chance to look at and work on it, and once ready for prime time, pull the #ifdef's out ... ? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)
And, actually, for some reason I hadn't thought of the tsearch as being another 'INDEX' type ... I crawl back over and be quiet now :) Oleg, as far as commits are concerned, I have no problems with extending the privileges to one of your guys for this, just email me seperately who, and I'll get it setup ... On Fri, 20 Jun 2003, Oleg Bartunov wrote: On Fri, 20 Jun 2003, Christopher Kings-Lynne wrote: Why part of the core distribution, and not just left as a loadable module, like it is now? The day I can go 'CREATE FULLTEXT INDEX ...' just like MySQL can I will be a very happy chappy... with new tserach v2 we're pretty close to that day. we need more testing, more suggestions and more documentation. There are several issues remains, mostly with core GiST not tsearch. The most important is concurrency support ! We've several times planned to work on it, but real life is rather complex thing :( Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Thu, 19 Jun 2003, Robert Treat wrote: Well, I suppose that history has shown that waiting on specific features causes trouble with postgresql development, but I don't see why a release can't be based around waiting for feature x as long as feature x is being actively worked on by trusted developers who have an endgame in sight. Everyone has an 'endgame in sight', at least when they ask for a release to be postponed ... but then their date keeps slipping, etc ... The thing is, if win32 is 'that close to being finished', then as soon as v7.4 is out, that code should be ready to throw in ... and the same for every other features that could 'postpone a release' ... I'd rather see the dev cycle shortened by a month, then extended ... ---(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] Two weeks to feature freeze
On Thu, 19 Jun 2003, Andrew Dunstan wrote: Maybe a better strategy would be to get a release out soon but not wait 6 months for another release which would contain the Win32 port and the PITR stuff (assuming those aren't done in time for this release). Just a thought. And definitely in agreement here ... I'd rather see a shortened dev cycle prompted by a big feature being added, then delaying a release because oh oh, I need another few weeks that draws out when something unexpected happens :( andrew Tom Lane wrote: Robert Treat [EMAIL PROTECTED] writes: Well, I suppose that history has shown that waiting on specific features causes trouble with postgresql development, but I don't see why a release can't be based around waiting for feature x as long as feature x is being actively worked on by trusted developers who have an endgame in sight. We have been led down that garden path before, and it's been a losing proposition every time. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)
On Thu, 19 Jun 2003, Oleg Bartunov wrote: I'm not sure if contrib/tsearch is a killer feature, but we hope to submit completely new version of tsearch V2 before July 1. Actually, we have stable code already used in some projects but currently lacking documentation. Several people are working on tutorial, reference guide. The problem is that Bruce seems is very overloaded and for sure he'll have many patches close to July 1. Is it possible to get rights to commit our changes ? Is there a strong reason why tsearch isn't in gborg? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)
On Fri, 20 Jun 2003, Oleg Bartunov wrote: Is there a strong reason why tsearch isn't in gborg? How gborg could help us submitting changes to pgsql CVS ? It wouldn't ... is there a reason why tsearch needs to be in the pgsql CVS any more then, say, ODBC drivers, or the tcl interface, or the python interface, or ... ? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)
On Fri, 20 Jun 2003, Tom Lane wrote: On Fri, 20 Jun 2003, The Hermit Hacker wrote: Is there a strong reason why tsearch isn't in gborg? I think text search is a pretty important facility that should eventually be part of the core distribution. It's more likely to get there from contrib than from gborg ... Why part of the core distribution, and not just left as a loadable module, like it is now? ---(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] Mirro updates
for the web, yes ... the new site doesn't support mirroring, as its highly database driven ... only thing still mirrorable, really, is the ftp server ... On Fri, 13 Jun 2003 [EMAIL PROTECTED] wrote: Hi every one, Is it normal that mirro site now all redirect to www.postgresql.org? It also seem that rsync is doing nothing when updating www... 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]) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Mirro updates
On Fri, 13 Jun 2003 [EMAIL PROTECTED] wrote: Hi vince, Hi Marc Although I understand why, I think it's a bit f a pity that there's no mirror of web anymore. For that it means that 1) every thing is now on your shoulders and that if anything goes wrong you've got no mirror to rely on. BUT the Good thing is it advocates for database replication as this could make mirrors run again :) God, I never enough thought about that ... a read-only replication would be *very* easy to setup ... Dave/Robert? Thoughts? ---(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] Okay, one mailing list problem still left...
shoujld be fixed now On Wed, 11 Jun 2003, Tom Lane wrote: ... pgsql-committers is not propagating. Bruce evidently applied a ton of patches last night, and I see no committers messages for any of 'em. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(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] Feature freeze date
'k, someone please test ... should all be setup now and 'auto-updating' hourly ... On Tue, 10 Jun 2003, Bruce Momjian wrote: [EMAIL PROTECTED] wrote: [ There is text before PGP section. ] [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We are 5 days away from the feature freeze date, but with the almost week of downtime we have had, I don't think we can stick to that date. Do we choose July 1 as feature freeze and July 15 as beta, or push beta start to Auguest 1? Well it would certainly be nice if CVS was working first. I am still getting the following error: $ cvs update /projects/cvsroot: no such repository Yes. I am even holding some of the patches because I am not sure if it makes sense to apply them when no one can check them. Marc says he will have it working in 6 hours. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze date
On Tue, 10 Jun 2003, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: We are 5 days away from the feature freeze date, but with the almost week of downtime we have had, I don't think we can stick to that date. Do we choose July 1 as feature freeze and July 15 as beta, or push beta start to Auguest 1? I don't think a week of partial downtime justifies a month's slip. The July 1/15 schedule seems like it might be a good plan though. I know I'm not going to be done editing error messages by June 15 ... July 1/15 sounds good to me as well ... ---(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] Feature freeze date
you have to give it a password ... any password, but a password non the less ... someone else asked me this also, and if I enter no passwd, I can get the same error message ... On Wed, 11 Jun 2003 [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, someone please test ... should all be setup now and 'auto-updating' hourly ... Not quite there yet: $cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login Logging in to :pserver:[EMAIL PROTECTED]:2401/projects/cvsroot CVS password: cvs login: authorization failed: server anoncvs.postgresql.org rejected access to /projects/cvsroot for user anoncvs - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200306102252 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+5pmwvJuQZxSWSsgRAkJ1AKCFCrFO3uSOZsapiELIRT3I/3j1cgCdFvwN +G5aCJaZg4kNMLezAsQxZm8= =t2BA -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] neptune back up and being configured ...
Just a quick note that we just brought neptune back up and are re-configuring her (getting the OS updated, patch applied for memory leak, etc) Teodor, I have your list of modules and am in the process of getting postgresql 7.3.3 installed ... will get the mailware DB back up and configured iwth the proper modules as soon as we have db.* pointing back at the right server later this aft ... this is just a note that there will be some downtime of the mailing lists, developer site and fts while we move them back to their proper machine ... we'll try and keep the downtime to a minimum ... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(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] Archives re-generating ...
http://archives.postgresql.org is slowly being re-generated from the base majordomo archive files, and the search index is ... indexing. Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cvs ETA?
?? cvs itself has been working for ages now ... anoncvs isn't ... or is that what you are using? On Thu, 5 Jun 2003, Dave Cramer wrote: Is there any ETA for cvs? Dave -- Dave Cramer [EMAIL PROTECTED] fastcrypt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] Anonymous CVS access
cvsweb.cgi is fixed ... working on the rest tonight ... On Wed, 4 Jun 2003, Joe Conway wrote: (moving to HACKERS) Bruno Wolff III wrote: The CVS server seems to be working again, but logging in with an empty password doesn't work. The web interface to anonymous CVS doesn't work either. [EMAIL PROTECTED] bruno]$ cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot login (Logging in to [EMAIL PROTECTED]) CVS password: /projects/cvsroot: no such repository cvs [login aborted]: authorization failed: server anoncvs.postgresql.org rejected access Yeah, I'm still getting failures on cvsup also: # cvsup -L 2 /root/postgres.cvsup Parsing supfile /root/postgres.cvsup Connecting to cvsup.postgresql.org Cannot connect to cvsup.postgresql.org: Connection refused Will retry at 21:14:17 Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RBLs ... I'm tired of spam ...
On Tue, 27 May 2003, Vince Vielhaber wrote: On Tue, 27 May 2003, Marc G. Fournier wrote: *Way* off topic ... but I'm tired of processing through 300 messages nightly of which 10 are stuff that need to be approved for the lists, and 290 are trash ... What are ppl using / trusting out there as far as Free RBLs are concerned? Avoid SPEWS. Ya, Spews is one of the 'evil ones' ... one of the blocks we were on in panama was in spews, and they don't seem to provide any way (that we could find) of removing the IPs when the offending server(s) were taken off the network ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RBLs ... I'm tired of spam ...
On Tue, 27 May 2003, scott.marlowe wrote: Another vote for SpamAssassin. We use it at work here and it's quite nice. It puts all the borderline spam in a holding area and sends you a daily email with all the topics / names listed and you can request those out of the spam bucket. It's configurable to the extreme. 'K, I haven't found *that* feature yet ... can you do this on a per-user basis as well, or is this a 'blanket, site wide' configuration ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.2 stuff
On Thu, 21 Jun 2001, Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: How far off is 7.2? Ages? Hopefully not. I'd like to see us get back on a reasonably short release cycle, like every six months or less --- the last couple major release cycles have been painfully long. So, maybe beta around Aug-Sep? Not speaking on behalf of core here; we haven't discussed release schedule at all yet. Just my personal $0.02. That's what I was seeing/hoping for also ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Universal admin frontend
something like this, web based, would be most cool ... have to be able to
monitor multiple port/backends too ...
On Tue, 19 Jun 2001, [iso-8859-1] Pedro Abelleira Seco wrote:
Hi all!
I'm thinking about starting a (serius) project to
bring a good graphical interface to the administration
and operation of postgresql, similar to what other
databases have.
The goal is to be able to do all the administrative
work of postgres in a single program. It would
include manage databases, tables, users, privileges
..., see/alter table contents, start/stop the
server(s), configure postgres, manage backups, have a
good SQL console, monitorize the backends, ...
As you can see it would be a superset of the pgaccess
capabilities but backwards compatible with it.
The program would be done in Java/Swing, being
automaticaly portable. The license would be the
license of PostgreSQL itself.
The cuestion is: Is there any posibility of such a
beast being ever included in the standard distribution
of PostgreSQL, if it prove util, well designed and
rock-solid, or it would not be accepted like a
standard add-on by the PostgreSQL hacker comunity?
(perhaps Java/Swing not acceptable, ...)
Thank you.
Pedro Abelleira Seco
___
Do You Yahoo!?
Yahoo! Messenger: Comunicación instantánea gratis con tu gente -
http://messenger.yahoo.es
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Doc translation
Tatsuo ... setting up a seperate CVS module for this does sound like a
great idea ... you already have access to the CVS repository, right? Can
you send me a tar file containing what you have so far, and I'll get it
into CVS and then you'll be able to update that at will?
If we set it up as:
pgsql-docs/ja
we could move the english docs out of pgsql itself and into this module
too, as:
pgsql-docs/en
and any other language too ...
On Mon, 18 Jun 2001, Tatsuo Ishii wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Hi, some PostgreSQL users in Japan have been translating 7.1 docs into
Japanese. I hope the work would finish within 1-2 months. My question
is how the translated docs could be merged into the doc source tree
once it is done. Maybe doc/ja/src/sgml?
Hmm, *should* they be merged into the source tree, or distributed as
a separate tarball? I'm concerned that they'd always be out of sync
with the English docs :-(
Right. However, it would be greater for Japanese users to have the
Japanese docs in the *official* distribution of PostgreSQL, than
getting them from other places. What about setting up a new CVS module
for the Japanese docs, isolated from the source and English doc
module(pgsql)?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Doc translation
On Mon, 18 Jun 2001, Peter Eisentraut wrote: Tatsuo Ishii writes: Hi, some PostgreSQL users in Japan have been translating 7.1 docs into Japanese. I hope the work would finish within 1-2 months. My question is how the translated docs could be merged into the doc source tree once it is done. Maybe doc/ja/src/sgml? A while ago I sent a proposal to -docs about how to handle this (basically doc/src/sgml-lang). No one protested so I was going to implement it; in fact, I already have in some private branch I have lying around here. It even includes some nice side-effects, such as fallback to English for incomplete translations (so you can look at the result while translation is still going on) and the integration of the translated SQL reference pages with the internationalized psql that is currently taking shape. (Someone else is working on a French translation and has been very anxious for this to happen, too.) I would not be in favour of a separate CVS module, for several reasons: First, it will marginalize the efforts. I bet there are a sufficient number of people how would be willing to track documentation upgrades and keep their language up-to-date. Second, the build machinery would get gratuitously complicated and spread around (makefiles, stylesheets, graphics, URL strings, etc.). Third, the (undoubtedly real) problem of keeping these translations up to date would not be helped by this at all. The maintainers of these translations will simply have to be honest to not label their documentation set as corresponding to version X.Y when the content is still based on the original documentation for X.(Y-2). About I don't want to download all this stuff I can't read: We already have chunked distribution tarballs. It would be possible to chunk out the files pertaining to a particular language (which would include the message catalogs as well). While other open source projects sometimes keep their entire documentation in a separate cvs module, they generally keep all languages together for the reasons given above. I definitely have no problems with this ... one comment about Tom's how to keep releases together point though ... that is what Tags/Branches are for ... as long as we tag all modules, things shouldn't fall out of sync ... But, if you already have a clean method of doign this, please, by all means, continue ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] LEFT JOIN ...
Morning ...
I'm trying to wrack my brain over something here, and no matter
how I try and look at it, I'm drawing a blank ...
I have two tables that are dependent on each other:
notes (86736 tuples) and note_links (173473 tuples)
The relationship is that one note can have several 'ppl' link'd to
it ...
I have a third table: calendar (11014 tuples) ... those calendar
entries link to a note.
So you have something like:
personA ---
personB --|-- note_links -- notes --[maybe]-- calendar entry
personC ---
now, the query I'm workign with is:
SELECT n.note, n.nid, n.type, c.act_type, c.status, nl.contact_lvl,
CASE WHEN c.act_start IS NULL
THEN date_part('epoch', n.added)
ELSE date_part('epoch', c.act_start)
END AS start
FROM note_links nl, notes n LEFT JOIN calendar c ON (n.nid
= c.nid)
WHERE (n.type = 'A' OR n.type = 'N' OR n.type = 'H' OR
n.type = 'C')
AND (nl.id = 15748 AND contact_lvl = 'company')
AND n.nid = nl.nid
ORDER BY start DESC;
Which explains out as:
NOTICE: QUERY PLAN:
Sort (cost=7446.32..7446.32 rows=1 width=88)
- Nested Loop (cost=306.52..7446.31 rows=1 width=88)
- Index Scan using note_links_id on note_links nl (cost=0.00..3.49 rows=1
width=16)
- Materialize (cost=6692.63..6692.63 rows=60015 width=72)
- Hash Join (cost=306.52..6692.63 rows=60015 width=72)
- Seq Scan on notes n (cost=0.00..2903.98 rows=60015 width=36)
- Hash (cost=206.22..206.22 rows=10122 width=36)
- Seq Scan on calendar c (cost=0.00..206.22 rows=10122
width=36)
EXPLAIN
and takes forever to run ...
Now, if I eliminate the LEFT JOIN part of the above, *one* tuple is
returned ... so even with the LEFT JOIN, only *one* tuple is going to be
returned ...
Is there some way to write the above so that it evaluates:
WHERE (n.type = 'A' OR n.type = 'N' OR n.type = 'H' OR n.type = 'C')
AND (nl.id = 15748 AND contact_lvl = 'company')
AND n.nid = nl.nid
first, so that it only has to do the LEFT JOIN on the *one* n.nid that is
returned, instead of the 86736 that are in the table?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Re: [SQL] LEFT JOIN ...
On Mon, 18 Jun 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: FROM note_links nl, notes n LEFT JOIN calendar c ON (n.nid = c.nid) WHERE (n.type = 'A' OR n.type = 'N' OR n.type = 'H' OR n.type = 'C') AND (nl.id = 15748 AND contact_lvl = 'company') AND n.nid = nl.nid ORDER BY start DESC; Is there some way to write the above so that it evaluates: first, so that it only has to do the LEFT JOIN on the *one* n.nid that is returned, instead of the 86736 that are in the table? Try adding ... AND n.nid = 15748 ... to the WHERE. It's not very bright about making that sort of transitive-equality deduction for itself... n.nid is the note id ... nl.id is the contact id ... I'm trying to pull out all notes for the company with an id of 15748: sepick=# select * from note_links where id = 15748; nid | id | contact_lvl | owner ---+---+-+--- 84691 | 15748 | company | f (1 row) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Re: [SQL] LEFT JOIN ...
Perfect, thank you ... i knew I was overlooking something obvious ... the
query just flies now ...
On Mon, 18 Jun 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Try adding ... AND n.nid = 15748 ... to the WHERE.
n.nid is the note id ... nl.id is the contact id ...
Ooops, I misread n.nid = nl.nid as n.nid = nl.id. Sorry for the
bogus advice.
Try rephrasing as
FROM (note_links nl JOIN notes n ON (n.nid = nl.nid))
LEFT JOIN calendar c ON (n.nid = c.nid)
WHERE ...
The way you were writing it forced the LEFT JOIN to be done first,
whereas what you want is for the note_links-to-notes join to be done
first. See
http://www.ca.postgresql.org/users-lounge/docs/7.1/postgres/explicit-joins.html
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Re: fts.postgresql.org ?
already fixed ...
On Fri, 15 Jun 2001, Oleg Bartunov wrote:
Marc,
when I try to reach http://fts.postgresql.org/ I see
http://www.hub.org/
what's happens ?
Regards,
Oleg
_
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: AW: [HACKERS] vacuum
On Wed, 13 Jun 2001, Zeugswetter Andreas SB wrote: Is there a relative consensus for how often to run vacuum? I have a table of about 8 columns that I fill with 100,000 items simply via a \i alarms.sql. After 1,000 items or so it gets extremely slow to fill with data, and will take over a day to fill the entire thing unless I run vacuum once a minute. You will have to tell us, what exactly your alarms.sql does, and what indexes your table has. Above behavior is certainly not to be expected in general, especially the vacuum once a minute is highly suspicious. For a series of insert only statements, the vacuum is not supposed to help at all, thus there must be an update hidden somewhere. the one question I'd have is what does the table size look like before/after this 'once a minute vacuum'? I have one client that has continuous UPDATEs happening to his table, no INSERTs, no DELETEs ... and his tables quicklky grow from a 8k table to 65Meg if there is no vacuum happening every few *hours* ... The other question is, what are your startup parameters? What sort of shared memory buffer are you working with? I image that VACUUM does a flush to disk, so are 1000 items filling your buffer(s), causing an almost continue fsync to disk for each INSERT after that ... so the VACUUM is clearing the buffer(s) to disk, giving your space again to do quick INSERTs for 1000 records again? ---(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: AW: [HACKERS] Postgres Replication
which I believe is what the rserv implementation in contrib currently does
... no?
its funny ... what is in contrib right now was developed in a weekend by
Vadim, put in contrib, yet nobody has either used it *or* seen fit to
submit patches to improve it ... ?
On Tue, 12 Jun 2001, Zeugswetter Andreas SB wrote:
Although
Postgres-R is a synchronous approach, I believe it is the closest to
the goal mentioned above. Here is an abstract of the advantages.
If you only want synchronous replication, why not simply use triggers ?
All you would then need is remote query access and two phase commit,
and maybe a little script that helps create the appropriate triggers.
Doing a replicate all or nothing approach that only works synchronous
is imho not flexible enough.
Andreas
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] Baby girl
trust me ... girls are soo much fun ... *roll eyes* *watches for
lightening*
On Mon, 11 Jun 2001, Mikheev, Vadim wrote:
I had a baby girl on Tuesday. I am working through my
backlogged emails
today.
Congratulations -:)
Vadim
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Max inserts / sec ... on any platform?
Morning all ...
Build a file with 100k INSERT statements in it, and run psql -f on
that file ... no BEGIN/END in the file, just straight INSERTs ... what is
the max throughput ppl can see?
I'm seeing reports of it maxing out on an AIX around 450, and on
an HP around 380 ... anyone seeing higher? and what sort of
configuration?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Dual-CPU slower then Single under HP?
On Wed, 6 Jun 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: The 4m:30s is running one process for 100K inserts ... with two CPUs/processes, it increases the time to process by almost 40% ... ? Do you mean two processes inserting into the same table? Yup ... I committed some changes recently that reduce the amount of contention involved in that scenario, but it's not released yet. So, this is one of those known problem, improved in v7.2 sort of issues? ---(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] Max inserts / sec ... on any platform?
Okay, based on 5k records and a couple of wallclock minutes being equal
to ~120sec, you are getting 41 inserts/sec?
On Wed, 6 Jun 2001, KuroiNeko wrote:
Build a file with 100k INSERT statements in it, and run psql -f on that
file ... no BEGIN/END in the file, just straight INSERTs ... what is the
max throughput ppl can see?
H Depends. Inserting up to 5,000 of Apache log records takes no
longer than a couple of wallclock minutes on Pentium-133 with 48 MB RAM and
no-cache Fujitsu IDE HDD (no DMA). (OK, OK, it's a home server, under my
desk :) No psql -f, though, using a home brewn dumb script runner. And yes,
no fsync and 10 inserts per transaction. Relation is currently 350,000+
long.
Not sure whether it makes interest. Care to send your file for me to try
it out? [bg]zip is OK.
--
LD$/G-$OAM$rJa$i$L
---(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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dual-CPU slower then Single under HP?
Great, thanks :)
On Wed, 6 Jun 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
So, this is one of those known problem, improved in v7.2 sort of issues?
Yup.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [CORE] Re: [HACKERS] Mirrors not tracking main ftp site?
okay, just removed the .hidden directory from the ftp server, which should
correct that ... I had setup that .hidden directory to be excluded though,
not sure why it was bothering things :(
On Mon, 4 Jun 2001, bpalmer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
However, it seems that the mirrors have a lot more stuff:
ftp://postgresql.readysetnet.com/pub/postgresql/dev/ shows dozens
of files back to 7.1beta6, and so do the other several I checked in
a random sample. Is the update mechanism failing to cause old files
to be removed from the mirrors?
Found the problem. Since rsync gets a perms denied from .hidden, it
refuses to delete files.
root@seraph:/root# ./rsync-postgres-ftp
receiving file list ... opendir(.hidden): Permission denied
done
IO error encountered - skipping file deletion
wrote 105 bytes read 20762 bytes 2782.27 bytes/sec
total size is 521221478 speedup is 24978.27
When I changed the script to:
#/usr/local/bin/rsync -avz --delete hub.org::postgresql-ftp
/mnt/ftpd/pub/postgresql
/usr/local/bin/rsync -avz --ignore-errors --delete
hub.org::postgresql-ftp /mnt/ftpd/pub/postgresql
It worked. People need to either use the --ignore-errors or have the
.hidden folder on the server removed.
- - Brandon
-
b. palmer, [EMAIL PROTECTED]pgp:crimelabs.net/bpalmer.pgp5
-BEGIN PGP SIGNATURE-
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOxxDFPYgmKoG+YbuEQLeiACeIhRJQ0HTZQCJc+aqHzqSfTods7IAnjEO
m9vtW2WRh3PMPXdlWeEBzTzY
=u6ep
-END PGP SIGNATURE-
---(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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] intelligence in writing a query ...
Tom, with all the work you've been doing inside planner and optimizer, has
there been anything done for 7.1.2 to make how a query is written cause
the backend to be more intelligent?
I'm playing with a query that I just don't like, since its taking ~3min to
run ...
It started as:
EXPLAIN SELECT distinct s.gid, s.created, count(i.title) AS images
FROM status s LEFT JOIN images i ON (s.gid = i.gid AND i.active),
personal_data pd, relationship_wanted rw
WHERE s.active AND s.status != 0
AND (s.gid = pd.gid AND pd.gender = 0)
AND (s.gid = rw.gid AND rw.gender = 1 )
AND ( ( age('now', pd.dob) '26 years' ) AND ( age('now', pd.dob)
'46 years' ) )
AND country IN ( 'US' )
GROUP BY s.gid,s.created
ORDER BY images desc;
NOTICE: QUERY PLAN:
Unique (cost=2365.87..2365.88 rows=1 width=37)
- Sort (cost=2365.87..2365.87 rows=1 width=37)
- Aggregate (cost=2365.86..2365.86 rows=1 width=37)
- Group (cost=2365.86..2365.86 rows=1 width=37)
- Sort (cost=2365.86..2365.86 rows=1 width=37)
- Nested Loop (cost=167.62..2365.85 rows=1 width=37)
- Nested Loop (cost=0.00..600.30 rows=1 width=8)
- Index Scan using personal_data_gender on
personal_data pd (cost=0.00..590.79 rows=4 width=4)
- Index Scan using relationship_wanted_gid on
relationship_wanted rw (cost=0.00..2.12 rows=1 width=4)
- Materialize (cost=1508.62..1508.62 rows=17128
width=29)
- Hash Join (cost=167.62..1508.62 rows=17128
width=29)
- Seq Scan on status s
(cost=0.00..566.24 rows=17128 width=12)
- Hash (cost=149.70..149.70 rows=7170
width=17)
- Seq Scan on images i
(cost=0.00..149.70 rows=7170 width=17)
EXPLAIN
And, after playing a bit, I've got it to:
2EXPLAIN SELECT distinct s.gid, s.created, count(i.title) AS images
FROM status s LEFT JOIN images i ON (s.gid = i.gid AND i.active),
relationship_wanted rw
WHERE s.active AND s.status != 0
AND EXISTS ( SELECT gid
FROM relationship_wanted
WHERE gender = 1 )
AND EXISTS ( SELECT gid
FROM personal_data
WHERE gender = 0
AND ( ( age('now', dob) '26 years' ) AND (
age('now', dob) '46 years' ) )
AND country IN ( 'US' ) )
GROUP BY s.gid,s.created
ORDER BY images desc;
NOTICE: QUERY PLAN:
Unique (cost=313742358.09..314445331.35 rows=9372977 width=29)
InitPlan
- Seq Scan on relationship_wanted (cost=0.00..1006.03 rows=1446 width=4)
- Index Scan using personal_data_gender on personal_data (cost=0.00..590.79
rows=4 width=4)
- Sort (cost=313742358.09..313742358.09 rows=93729769 width=29)
- Aggregate (cost=285211774.88..292241507.54 rows=93729769 width=29)
- Group (cost=285211774.88..289898263.32 rows=937297688 width=29)
- Sort (cost=285211774.88..285211774.88 rows=937297688 width=29)
- Result (cost=167.62..24262791.77 rows=937297688
width=29)
- Nested Loop (cost=167.62..24262791.77
rows=937297688 width=29)
- Hash Join (cost=167.62..1508.62 rows=17128
width=29)
- Seq Scan on status s
(cost=0.00..566.24 rows=17128 width=12)
- Hash (cost=149.70..149.70 rows=7170
width=17)
- Seq Scan on images i
(cost=0.00..149.70 rows=7170 width=17)
- Seq Scan on relationship_wanted rw
(cost=0.00..869.22 rows=54722 width=0)
EXPLAIN
Not much of an improvement ...
The 'personal_data' EXISTS clause:
SELECT gid
FROM personal_data
WHERE gender = 0
AND ( ( age('now', dob) '26 years' ) AND ( age('now', dob) '46 years' ) )
AND country IN ( 'US' ) ;
NOTICE: QUERY PLAN:
Index Scan using personal_data_gender on personal_data (cost=0.00..590.79 rows=4
width=4)
EXPLAIN
returns 1893 rows, while status contains 26260 rows ... status and
personal_data have a 1-to-1 relationship, so out of 26260 rows in status,
*max* I'm ever going to deal with are the 1893 that are found in
personal_data ...
so, what I'd like to do is have the subselect on personal_data used first,
so as to reduce the set of data that the rest of the query will work only
on those 1893 gid's, instead of all 26260 of them ...
Re: [HACKERS] appendum: Re: *really* simple select doesn't useindices ...
On Tue, 29 May 2001, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: The column 'zip' is of type text. As such, indices will not be used except in the case when the where clause is WHERE zip ~ '^text' for btree indices. Uh ... nonsense. Oh good, I was worried there for a sec ... :) On Tue, 29 May 2001, Marc G. Fournier wrote: globalmatch=# vacuum verbose analyze locations; NOTICE: --Relation locations-- NOTICE: Pages 1395: Changed 0, reaped 0, Empty 0, New 0; Tup 123571: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 76, MaxLen 124; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.11s/0.00u sec. globalmatch=# explain SELECT location from locations WHERE zip = '80012'; NOTICE: QUERY PLAN: Seq Scan on locations (cost=0.00..2939.64 rows=4217 width=16) Okay, so it thinks that zip = '80012' will match 4217 out of 123571 rows, which is more than enough to drive it to a sequential scan (with an average of more than three matched rows on every page of the relation, there'd be no I/O savings at all from consulting the index). Since the real number of matches is only 1, this estimate is obviously way off. In 7.1 the estimate is being driven by the frequency of the most common value in the column --- what is the most common value? If you're lucky, the most common value is a dummy (empty string, maybe) that you could replace by NULL with a few simple changes in application logic. 7.1 is smart enough to distinguish NULL from real data values in its estimates. If you're not lucky, there really are a few values that are far more common than average, in which case you're stuck unless you want to run development sources. Current sources should do a lot better on that kind of data distribution. Hit it right on the mark: zip | cnt ---+--- | 81403 00210 | 1 00211 | 1 Will look at the code and see what I can do abuot that NULL issue ... thanks :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Not released yet, but could someone take a quick peak...
Sorry for delay ... just built using the .tar.gz file as below if someone
wants to check it to confirm ... for those with shell access on the
server, just ftp to it and login as yourself, and cd to
~pgsql/ftp/pub/source/v7.1.2 ...
if all looks well, I'll put out a more general announce later this evening
after some of the mirrors have had a chance to download ...
On Wed, 23 May 2001, Peter Eisentraut wrote:
The Hermit Hacker writes:
which ones should I pull in? the ones in ~/ftp/pub/doc/7.1? or is there
newer along that tree that we need to generate?
You can take
~petere/pg71/pgsql/doc/src/postgres.tar.gz
The man.tar.gz from the ftp directory is okay.
On Tue, 22 May 2001, Peter Eisentraut wrote:
The Hermit Hacker writes:
ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
Just want a second opinion before I announce more publicly ...
It contains the 7.2 branch documentation set. No go...
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Not released yet, but could someone take a quick peak...
which ones should I pull in? the ones in ~/ftp/pub/doc/7.1? or is there
newer along that tree that we need to generate?
On Tue, 22 May 2001, Peter Eisentraut wrote:
The Hermit Hacker writes:
ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
Just want a second opinion before I announce more publicly ...
It contains the 7.2 branch documentation set. No go...
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Not released yet, but could someone take a quick peak...
all mirrors use rsync to update their code, and all of those that are
listed at www.postgresql.org, both ftp and www, are no more then 2 days
old (Vince, it is two days we set it at, right?) ...
On Wed, 23 May 2001, bpalmer wrote:
On Wed, 23 May 2001, Tom Lane wrote:
every time I've tried it for the last several weeks. The mirrors seem
to have a hard time getting in, too --- digex doesn't have 7.1.2 yet,
for example.
Does digex use rsync? That's how i'm getting the files, so it shouldn't
care about ftp access..
- brandon
b. palmer, [EMAIL PROTECTED]
pgp: www.crimelabs.net/bpalmer.pgp5
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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
