[HACKERS] Anyone tried compiling postgresql with the Intel compilers?
Hi has anyone tried Intel's compiler yet? http://developer.intel.com/software/products/eval/ Just wondering what would happen. Cheerio, Link. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Hot spare PSQL server
Darren == Darren Johnson [EMAIL PROTECTED] writes: Unfortunatly this seems to be asynchronous replication (you manually have to initiate the syncronization)... I'd like to have synchronous replication... Darren There is a synchronous replication project here... Darren http://www.greatbridge.org/project/pgreplication/projdisplay.php Darren We currently have a working model based on Darren PostgreSQL-6.4.2, and are working on implementing the Darren ideas in PostgreSQL-7.1.3. The site is very broken... Where can I find information on how it works etc? The FAQ link leads to an empty page... -- Turbo __ _ Debian GNU Unix _IS_ user friendly - it's just ^/ /(_)_ __ _ ___ __ selective about who its friends are / / | | '_ \| | | \ \/ / Debian Certified Linux Developer _ /// / /__| | | | | |_| |Turbo Fredriksson [EMAIL PROTECTED] \\\/ \/_|_| |_|\__,_/_/\_\ Stockholm/Sweden 767 pits radar colonel bomb congress CIA critical $400 million in gold bullion counter-intelligence nuclear nitrate strategic Khaddafi killed [See http://www.aclu.org/echelonwatch/index.html for more about this] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] MySQL development MUST immdediately cease - Due to
I agree. This mailing list is not a forum to express aversions to other software products, no matter how justified these aversions are. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] triggers procedures listing URGENT
Within psql examine the system tables pg_proc pg_trigger Refer to the documentation Chapter System Catalogs Regards, Christoph PS I was sending this mail yesterday to '[EMAIL PROTECTED]' but it seemed to disappear, at least I did not get it back. Has anybody experienced similar effects? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Major change to CVS effective immediately ...
* Marc G. Fournier [EMAIL PROTECTED] wrote: | | anoncvs.postgresql.org is going to be out of sync until, most likely, | tomorrow, for anyone trying to use that ... anoncvs is *no longer* | available through the main cvs repository either ... Is anoncvs.postgresql.org working yet ? I just tried : # cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot login and # cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login with postgresql as password. In both cases the response was this : cvs [login aborted]: authorization failed: server anoncvs.postgresql.org rejected access regards, Gunnar -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] slow UNIONing
I experienced that UNIONs in 7.1.1 are rather slow: tir=# explain (select nev from cikk) union (select tevekenyseg from log); NOTICE: QUERY PLAN: Unique (cost=667.63..687.18 rows=782 width=12) - Sort (cost=667.63..667.63 rows=7817 width=12) - Append (cost=0.00..162.17 rows=7817 width=12) - Subquery Scan *SELECT* 1 (cost=0.00..28.16 rows=1316 width=12) - Seq Scan on cikk (cost=0.00..28.16 rows=1316 width=12) - Subquery Scan *SELECT* 2 (cost=0.00..134.01 rows=6501 width=12) - Seq Scan on log (cost=0.00..134.01 rows=6501 width=12) Of course a simple SELECT is fast: tir=# explain select nev from cikk; NOTICE: QUERY PLAN: Seq Scan on cikk (cost=0.00..28.16 rows=1316 width=12) For me it seems to be slow due to the sorting. Is this right? Is this normal at all? Is it possible to make it faster? TIA, Zoltan -- Kov\'acs, Zolt\'an [EMAIL PROTECTED] http://www.math.u-szeged.hu/~kovzol ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] CVS access problem
I'm following the instructions on the web site which say's: --- Do an initial login to the CVS server: $ cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot login You will be prompted for a password; enter 'postgresql'. You should only need to do this once, since the password will be saved in .cvspass in your home directory. This doesn't seem to work. Is there something else I should use instead? Thanks. Mark ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS access problem
Marc G. Fournier wrote: anoncvs.postgresql.org, not cvs.postgresql.org ... Arne posted the wrong one :( Whoops! I'm sorry, I overlooked that! Arne Weiner. ---(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] Large objects and ecpg
Hi all, Can I use ecpg with large objects? All examples in documentation are for libpq. Thanks Shridhar _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] x = NULL
Peter Eisentraut [EMAIL PROTECTED] writes: I'm getting tired of this, so unless someone can present a reason not to, I'll implement a GUC parameter to turn this off -- and turn it off by default. You'll have to push the switch-driven transformation into analyze.c --- it is not okay for gram.y to look at GUC parameters. But as long as you do it correctly, I'm for it. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Beta time
Attached is the CONSTR_PRIMARY switch block from command.c. I've marked the problem test with '@@'. Basically the patch all seems to work properly, except that it doesn't recognise existing primarty keys. ie. You can go ALTER TABLE test ADD PRIMARY KEY(a) multiple times and it will keep adding a primary key. My ADD UNIQUE patch that has been committed is virtually identical, and has no such problem. Chris -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 18 September 2001 12:41 PM To: Christopher Kings-Lynne Cc: Bruce Momjian; PostgreSQL-development Subject: Re: [HACKERS] Beta time Christopher Kings-Lynne [EMAIL PROTECTED] writes: I am checking the indexStruct-indisprimary field, but it always resolves to false. indisunique works fine. It is a trivial change to the ADD UNIQUE code, but it doesn't work. Viewing the system catalogs and '\d' both show the indices as primary, but the SearchSysCache funtion believes that they are not. Doesn't make any sense to me either. Want to post your code? regards, tom lane command.c ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] x = NULL
I'm getting tired of this, so unless someone can present a reason not to, I'll implement a GUC parameter to turn this off -- and turn it off by default. I wrote: The x = NULL hack keeps biting people. Innocent people should not be exposed to incorrect behaviour because of (supposed) MS Access breakage. I strongly urge that we do one of the following: 1) Provide a tunable knob to turn this on (cf. KSQO) 2) Confine this to the ODBC driver somehow (which could be done via #1) Actually, last time we discussed this there was some confusion whether Access actually had the bug in question. That might be worth figuring out. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] slow UNIONing
Kovacs, A 'union all' will be much faster than 'union'. 'union all' returns all results from both queries, whereas 'union' will return all distinct records. The 'union' requires a sort and a merge to remove the duplicate values. Below are explain output for a union query and a union all query. files=# explain files-# select dummy from test files-# union all files-# select dummy from test; NOTICE: QUERY PLAN: Append (cost=0.00..40.00 rows=2000 width=12) - Subquery Scan *SELECT* 1 (cost=0.00..20.00 rows=1000 width=12) - Seq Scan on test (cost=0.00..20.00 rows=1000 width=12) - Subquery Scan *SELECT* 2 (cost=0.00..20.00 rows=1000 width=12) - Seq Scan on test (cost=0.00..20.00 rows=1000 width=12) EXPLAIN files=# explain files-# select dummy from test files-# union files-# select dummy from test; NOTICE: QUERY PLAN: Unique (cost=149.66..154.66 rows=200 width=12) - Sort (cost=149.66..149.66 rows=2000 width=12) - Append (cost=0.00..40.00 rows=2000 width=12) - Subquery Scan *SELECT* 1 (cost=0.00..20.00 rows=1000 width=12) - Seq Scan on test (cost=0.00..20.00 rows=1000 width=12) - Subquery Scan *SELECT* 2 (cost=0.00..20.00 rows=1000 width=12) - Seq Scan on test (cost=0.00..20.00 rows=1000 width=12) EXPLAIN files=# thanks, --Barry Kovacs Zoltan wrote: I experienced that UNIONs in 7.1.1 are rather slow: tir=# explain (select nev from cikk) union (select tevekenyseg from log); NOTICE: QUERY PLAN: Unique (cost=667.63..687.18 rows=782 width=12) - Sort (cost=667.63..667.63 rows=7817 width=12) - Append (cost=0.00..162.17 rows=7817 width=12) - Subquery Scan *SELECT* 1 (cost=0.00..28.16 rows=1316 width=12) - Seq Scan on cikk (cost=0.00..28.16 rows=1316 width=12) - Subquery Scan *SELECT* 2 (cost=0.00..134.01 rows=6501 width=12) - Seq Scan on log (cost=0.00..134.01 rows=6501 width=12) Of course a simple SELECT is fast: tir=# explain select nev from cikk; NOTICE: QUERY PLAN: Seq Scan on cikk (cost=0.00..28.16 rows=1316 width=12) For me it seems to be slow due to the sorting. Is this right? Is this normal at all? Is it possible to make it faster? TIA, Zoltan ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS access problem
The location of the cvs repository recently changed. It is know accessible as :pserver:userid@cvs.postgresql.org:/cvsroot Your commandline for an initial login should be: $ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login Arne Weiner. news.grapid1.mi.home.com wrote: I'm following the instructions on the web site which say's: --- Do an initial login to the CVS server: $ cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot login You will be prompted for a password; enter 'postgresql'. You should only need to do this once, since the password will be saved in .cvspass in your home directory. This doesn't seem to work. Is there something else I should use instead? Thanks. Mark ---(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] CVS access problem
The location of the cvs repository recently changed. It is know accessible as :pserver:userid@cvs.postgresql.org:/cvsroot Your commandline for an initial login should be: $ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login Arne Weiner. I'm trying that exact command line above but I get this: Fatal error, aborting. anoncvs: no such user cvs login: authorization failed: server cvs.postgresql.org rejected access to /cvs root for user anoncvs Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS access problem
anoncvs.postgresql.org, not cvs.postgresql.org ... Arne posted the wrong one :( On Tue, 18 Sep 2001, Christopher Kings-Lynne wrote: The location of the cvs repository recently changed. It is know accessible as :pserver:userid@cvs.postgresql.org:/cvsroot Your commandline for an initial login should be: $ cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login Arne Weiner. I'm trying that exact command line above but I get this: Fatal error, aborting. anoncvs: no such user cvs login: authorization failed: server cvs.postgresql.org rejected access to /cvs root for user anoncvs Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Trans-transactions cursors
Chamanya wrote: I am currently building a small web based app, with postgres as back end. I found that in ecpg you can declare and use cursor without declaring a transaction. In several places I have used cursors for selects only. That's the only way I found to make ecpg fetch multiple rows. And in ecpg I have to give an explicit open cursor statement to make fetching possible. That's simply because ecpg starts a new transaction on any SQL statement if no transaction is active. I consider this (autocommit on) one of the worst traps you can lay for yourself. Christof ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Major change to CVS effective immediately ...
Thus spake Marc G. Fournier
This will most likely screw some ppl up, and fix others ...
CVSROOT has now moved to the new machine, finally ... and I've cleaned up
pathing ... and CVS_RSH=ssh now works again too ...
So, now CVSROOT is accessible as:
:pserver:userid@cvs.postgresql.org:/cvsroot
-or-
:ext:userid@cvs.postgresql.org:/cvsroot
- where CVS_RSH is set to ssh
None of this helps me. I still can't get into that system. Can you
please check this and get me back in. If I can't get in I will have
to move PyGreSQL back to my own CVS repository and I think it is good
for both projects to leave it where it is. Will you be in today? I
can call you later to discuss this and hopefully resolve it.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] MySQL development MUST immdediately cease - Due to
To whoever sent this posting (being Al Dev, or someone spoofing), Please stop posting to the PostgreSQL mailing lists. You are not helping PostgreSQL with your postings, instead you are inciting anger and hostility. Cease and desist these postings immediately. Justin Clift peace_flower wrote: This is a immediate order to COMPLETELY STOP and CEASE all development of MySQL database server. This is due to rapid changes in the Global Economic conditions.. You do not have time to deal with one powerful SQL server like PostgreSQL, where do you have time to deal with two types of SQL servers. Question is why have two?? There is no time to deal with two open source SQL servers. After doing research, it is recommended that you stick with just PostgreSQL. With huge amount of efforts MySQL can be brought closer to PostgreSQL level (and perhaps it may NEVER be possible to bring MySQL to the level of technology of PostgreSQL). Even if it is done it will be a waste of time.. The WORLD economy started taking nose dive for the last 2 years. Last year a mild global economic recession started which forced thousands of companies world-wide closing down. Last year millions of dot-com went bust. It is predicted that there is a impending World-War-III like situation is developing in the middle-east and Afghanistan which may have significant effect in Asian and European countries. But that may NOT have lot of economic effects on North/South American countries like Brazil, USA, Canada, Mexico.. Nevertheless, overall economy of the globe will get the impact. And, hence drop off the MySQL now and migrate all your data to PostgreSQL.. By the way, PostgreSQL runs on all platforms - All unixes, linux, Apple Macintosh and MS Windows 98/NT/2000 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
