[GENERAL] How do I reinstall libeay32.dll
Dear friends, After having installed Crystal Reports on my machine, I get the following error message trying to open PgAdminIII: “The ordinal 2821 could not be located in the dynamic link library LIBEAY32.dll.” A search on the pgsql-mailing lists indicates that CR has overwritten my libeay32.dll-file. What is the easiest way to reinstall the right version? I am using PostgreSQL 8.0 on Windows XP. Hoping that somebody could help me. Best regards Jon Christian
Re: [GENERAL] Limits of SQL
Am Donnerstag, den 02.06.2005, 12:46 -0700 schrieb Ben: > You mean, you want to be able to say something like: > > select isConnected(a,b) > > and get back a true/false, or maybe the path? > > That seems quite doable in SQL, assuming you either store those results > and simply use sql to retrieve them, or use a stored proc to compute the > result each time. These are both things I want to avoid. I am not trying to solve a real world problem, I want to understand the limits of SQL. And it seems that a plain SELECT that tells me if a path exists is not possible. However I just read nested sets (thx for the link, Sean). Maybe a tricky representation does it. Sincerely, Joachim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] How do I reinstall libeay32.dll
Title: Message Just get the latest openssl binary download from their site (linked from their site, that is, I think their main site only carries source) and just copy over the file. Make sure you replace *both* openssl DLLs - ilbeay32.dll and ssleay32.dll - they should always be the same version. //Magnus -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Christian OttersenSent: den 4 juni 2005 10:54To: pgsql-general@postgresql.orgSubject: [GENERAL] How do I reinstall libeay32.dll Dear friends, After having installed Crystal Reports on my machine, I get the following error message trying to open PgAdminIII: “The ordinal 2821 could not be located in the dynamic link library LIBEAY32.dll.” A search on the pgsql-mailing lists indicates that CR has overwritten my libeay32.dll-file. What is the easiest way to reinstall the right version? I am using PostgreSQL 8.0 on Windows XP. Hoping that somebody could help me. Best regards Jon Christian
Re: [GENERAL] Limits of SQL
On Sat, Jun 04, 2005 at 11:31:02 +0200, Joachim Zobel <[EMAIL PROTECTED]> wrote: > > These are both things I want to avoid. I am not trying to solve a real > world problem, I want to understand the limits of SQL. And it seems that > a plain SELECT that tells me if a path exists is not possible. However I > just read nested sets (thx for the link, Sean). Maybe a tricky > representation does it. When 'WITH' gets implemented then you should be able to do this. I think there was some recent talk about that, but I don't know if it is going to make it in to 8.1. We'll know in about a month though. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] PostgreSQL vs. InnoDB performance
Christopher Browne <[EMAIL PROTECTED]> writes: > After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Marco Colombo) > belched out: >> On Fri, 2005-06-03 at 11:38 +0200, Peter Eisentraut wrote: >>> Am Freitag, 3. Juni 2005 00:36 schrieb Peter Eisentraut: >>> > On a particular system, loading 1 million rows (100 bytes, nothing >>> > fancy) into PostgreSQL one transaction at a time takes about 90 >>> > minutes. Doing the same in MySQL/InnoDB takes about 3 minutes. InnoDB >>> > is supposed to have a similar level of functionality as far as the >>> > storage manager is concerned, so I'm puzzled about how this can be. >>> > Does anyone know whether InnoDB is taking some kind of questionable >>> > shortcuts it doesn't tell me about? >>> >>> So here's another little gem about our friends from Uppsala: If you create >>> a >>> table with InnoDB storage and your server does not have InnoDB configured, >>> it >>> falls back to MyISAM without telling you. >> >> Silently falling back to something unexpected seems to be quite common >> there. For sure it's not the only case. :-| >> >>> As it turns out, the test done with PostgreSQL vs. real InnoDB results in >>> just >>> about identical timings (90 min). The test done using PostgreSQL with >>> fsync >>> off vs. MyISAM also results in about identical timings (3 min). >> >> The hardware seems to be the bottleneck. Try improving the performance >> of your disk systems. It's very unlikely to get _exactly_ the same >> figures from such two different RDBMS. You expect them to be close, but >> not identical. > > If the bottleneck is in the identical place, and they are otherwise > well-tuned, it is actually *not* that surprising that the timings for > "PostgreSQL vs real InnoDB" would be pretty close. > > If both are being bottlenecked by the same notion of "how fast does > the disk spin," then the differences in performance won't be dramatic. Yes, I also think so. One transaction is one transaction, so if neither database is lying, they really should come out with similar results. Having said that, I'm getting much better speed doing very simple transactions, and that is on the low end hardware (Dual PIII 1GHz, IDE disk 7200rpm, Linux 2.6, ext3fs with barrier=1 mount option - so the disk cache can safely be left turned on). I'm getting around 950 transactions with the attached app. Also, observing the output of the iostat utility, it can be seen that disk is quite busy and that it is running with the number of writes comparable to the number of transactions (and the average size of one write operation is near 8KB, which is the default PostgreSQL's block size). extended device statistics device mgr/s mgw/sr/sw/skr/skw/s size queue wait svc_t %b hda0 9950.4 951.3 1.7 7785.38.2 4.24.4 0.6 59 zcalusic=# \d words Table "public.words" Column | Type | Modifiers ++--- word | character varying(256) | #! /usr/bin/perl use DBI; use strict; use warnings; $| = 1; my $dbh = DBI->connect('dbi:Pg:dbname=zcalusic', 'zcalusic', 'useyours', {PrintError => 1, RaiseError => 1, AutoCommit => 1}); my $sth = $dbh->prepare("INSERT INTO words VALUES (?)"); $dbh->do("TRUNCATE TABLE words"); open(WORDS, ") { chomp $word; $sth->execute($word); $sofar++; if (($time = time()) > $oldtime) { print int($sofar / ($time - $start)), " inserts/second \r"; $oldtime = $time; } } print int($sofar / ($time - $start)), " inserts/second\n"; close(WORDS); exit 0; -- Zlatko ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] PostgreSQL vs. InnoDB performance
Scott Marlowe <[EMAIL PROTECTED]> writes: > Also, I wonder how well both databases will survive having power removed > while under heavy load... It depends more on the underlying hardware setup (disk/raid array) than on the any other aspect (like OS). Assuming you have fsync enabled, of course. There is a very interesting test that you can do (if you have two machines) to see what happens if one of your machines suddenly loses power. You can read about that here: http://www.livejournal.com/users/brad/2116715.html Most of todays IDE disks comes with write caching turned on by default, and if you lose power, you'll lose some of unwriten data for sure. Turn it off, or if you're using ext3 on Linux 2.6, you can mount your partitions with barrier=1 option which will make your fsyncs safe and still let you get some benefits from write caching. Of course, your production quality database would be on the powerful SCSI disk array behind a good RAID controller. Question there is have you bought the (often) additional battery backup for your RAID card? If notm turn the write caching off, once again, or you WILL lose your data and corrupt your database if you suddenly lose power. -- Zlatko ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] How do I reinstall libeay32.dll
Title: Message Sorry, I am a bit newbie to this. I am not able to find links to these files on the openssl web pages. I have tried searhing the internet, and find a lot of places to dowload them, but mostly without information about the version number and seldom the two files at the same place (the one place I found both it seemed they had different version numbers. Any suggestions? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hagander Sent: 4. juni 2005 13:44 To: Jon Christian Ottersen; pgsql-general@postgresql.org Subject: Re: [GENERAL] How do I reinstall libeay32.dll Just get the latest openssl binary download from their site (linked from their site, that is, I think their main site only carries source) and just copy over the file. Make sure you replace *both* openssl DLLs - ilbeay32.dll and ssleay32.dll - they should always be the same version. //Magnus -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Christian Ottersen Sent: den 4 juni 2005 10:54 To: pgsql-general@postgresql.org Subject: [GENERAL] How do I reinstall libeay32.dll Dear friends, After having installed Crystal Reports on my machine, I get the following error message trying to open PgAdminIII: “The ordinal 2821 could not be located in the dynamic link library LIBEAY32.dll.” A search on the pgsql-mailing lists indicates that CR has overwritten my libeay32.dll-file. What is the easiest way to reinstall the right version? I am using PostgreSQL 8.0 on Windows XP. Hoping that somebody could help me. Best regards Jon Christian
Re: [GENERAL] Old problem needs solution
Ok, that did it. All fixed up and upgraded to 8. The command for gentoo to rebuild WITH the pg-hier patch is (for those that might see this question again): # USE="pg-hier" emerge "=postgresql-7.4.7-r2" -vD # or whatever latest 7.x version is at that time. Backup the data, etc. Then when you're done just # emerge postgresql -vD to update to the latest version which SHOULD NOT have the patch enabled by default. Do another initdb and restore your data. I'm wondering how it got there in the first place. Wonder if there was a bad release where that flag was enabled by default. Oh well, better now. Thanks for all the help! G Russell Smith wrote: On Sat, 4 Jun 2005 09:25 am, Alvaro Herrera wrote: On Fri, Jun 03, 2005 at 05:55:36PM -0500, Gerald D. Anderson wrote: [snip] I guess your build with the "use flag" wasn't successful. I think you have two choices: 1. really build with the patch installed, and dump your data using that Given the number of reports we have had about this specific bug on the lists. I have take the time to submit a bug directly to the gentoo project. Hopefully that can fit it properly and we will not see this happening again. For reference the bug is at: http://bugs.gentoo.org/show_bug.cgi?id=94965 ---(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: [GENERAL] How do I reinstall libeay32.dll
Title: Message The link is on http://www.openssl.org/related/binaries.html, and it points to http://www.slproweb.com/products/Win32OpenSSL.html. Which has the required download links. You want version 0.9.7g. //Magnus -Original Message-From: Jon Christian Ottersen [mailto:[EMAIL PROTECTED] Sent: den 4 juni 2005 19:37To: Magnus Hagander; 'Jon Christian Ottersen'; pgsql-general@postgresql.orgSubject: RE: [GENERAL] How do I reinstall libeay32.dll Sorry, I am a bit newbie to this. I am not able to find links to these files on the openssl web pages. I have tried searhing the internet, and find a lot of places to dowload them, but mostly without information about the version number and seldom the two files at the same place (the one place I found both it seemed they had different version numbers. Any suggestions? -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus HaganderSent: 4. juni 2005 13:44To: Jon Christian Ottersen; pgsql-general@postgresql.orgSubject: Re: [GENERAL] How do I reinstall libeay32.dll Just get the latest openssl binary download from their site (linked from their site, that is, I think their main site only carries source) and just copy over the file. Make sure you replace *both* openssl DLLs - ilbeay32.dll and ssleay32.dll - they should always be the same version. //Magnus -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Christian OttersenSent: den 4 juni 2005 10:54To: pgsql-general@postgresql.orgSubject: [GENERAL] How do I reinstall libeay32.dll Dear friends, After having installed Crystal Reports on my machine, I get the following error message trying to open PgAdminIII: “The ordinal 2821 could not be located in the dynamic link library LIBEAY32.dll.” A search on the pgsql-mailing lists indicates that CR has overwritten my libeay32.dll-file. What is the easiest way to reinstall the right version? I am using PostgreSQL 8.0 on Windows XP. Hoping that somebody could help me. Best regards Jon Christian
Re: [GENERAL] postgresql books
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] would write: > "Gevik babakhani" <[EMAIL PROTECTED]> wrote: > >> Beside the documentation, which pg book would you recommend? Which one is >> your personal favorite pg book? > > I saw an O'Reilly book [1] this afternoon at a bookshop here in > Paris .. 'had to fight the urge to get my credit card out ... :-) > Anyone know if it's any good ? It's a bit dated, being based on the state of things in the 6.5/7.0 days, but is still quite useful. It's frankly the one I keep on my desk the most, as I particularly like its summary of the built-in functions of any of the books out there. The Douglas & Douglas book has one of the best descriptions going on how to read query plans, so it's plenty useful in that regard... -- (reverse (concatenate 'string "gro.mca" "@" "enworbbc")) http://linuxdatabases.info/info/slony.html Donny: Are these the Nazis, Walter? Walter: No, Donny, these men are nihilists. There's nothing to be afraid of. -- The Big Lebowski ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Limits of SQL
Am Samstag, den 04.06.2005, 07:38 -0500 schrieb Bruno Wolff III: > On Sat, Jun 04, 2005 at 11:31:02 +0200, > Joachim Zobel <[EMAIL PROTECTED]> wrote: > > > > ... And it seems that > > a plain SELECT that tells me if a path exists is not possible... > > When 'WITH' gets implemented then you should be able to do this. I think > there was some recent talk about that, but I don't know if it is going to > make it in to 8.1. We'll know in about a month though. So WITH will allow recursion so I can walk the graph, right? Does this mean I can recursively join until a terminating condition is reached? Sincerely, Joachim ---(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: [GENERAL] Limits of SQL
On Sat, Jun 04, 2005 at 21:53:24 +0200, Joachim Zobel <[EMAIL PROTECTED]> wrote: > Am Samstag, den 04.06.2005, 07:38 -0500 schrieb Bruno Wolff III: > > On Sat, Jun 04, 2005 at 11:31:02 +0200, > > Joachim Zobel <[EMAIL PROTECTED]> wrote: > > > > > > ... And it seems that > > > a plain SELECT that tells me if a path exists is not possible... > > > > When 'WITH' gets implemented then you should be able to do this. I think > > there was some recent talk about that, but I don't know if it is going to > > make it in to 8.1. We'll know in about a month though. > > So WITH will allow recursion so I can walk the graph, right? Does this > mean I can recursively join until a terminating condition is reached? It can be used to compute transitive closures, which I think is what you are really looking for. If you look at the TODO page (http://www.postgresql.org/docs/faqs.TODO.html) you will see two entries for WITH under Exotic Features: Add SQL99 WITH clause to SELECT Add SQL99 WITH RECURSIVE to SELECT There is a short example of this on pages 439-440 of "SQL for Smarties" second edition. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Rollback on Error
This has already been implemented in CVS as a psql \set variable: ON_ERROR_ROLLBACK = 'interactive' and will appear in 8.1. --- Michael Paesold wrote: > Tom Lane wrote: > > > "Michael Paesold" <[EMAIL PROTECTED]> writes: > > > On the other hand, the scenario of a psql option (read: I have > > > given up the idea of a backend implementation) to rollback only > > > last statement on error is quite different. > > > > Sure (and we already have one for autocommit). But I thought you were > > asking about a backend implementation. > > I have implemented what I have suggested for psql. I have attached a first > patch for review here, because I have a few questions. Also I want to make > sure the whole thing is reasonable. > > I have named the option "IMPLICIT_SAVEPOINTS", because that's what it is. If > someone has a better name that would describe the purpose of the feature, I > am happy to change it. > > The feature is activated, if > * \set IMPLICIT_SAVEPOINTS 'on' > * connection is in "idle in transaction" state > * psql session is interactive > > The code executes an implicit "SAVEPOINT pg_internal_psql" in > common.c/SendQuery to which it will try to rollback to, if the executed > query fails. > > Open questions: > * Should psql print a notice in the case of that rollback? > Something like "Rollback of last statement successful."? > > * What is currently missing, is a detection of \i ... obviously this feature > should not be used for each query in \i. Perhaps only for the whole \i > command? > So what should I do to detect \i? > Add an extra argument to MainLoop, SendQuery and process_file()? (many > changes) > Add a global variable in common.c/h (e.g. bool > deactivate_implicit_savepoints) that can be used in process_file to > temporarily deactivate the code path? > (more local changes, but rather a hack imho) > > Please have a look at the patch and comment. > > Best Regards, > Michael Paesold [ Attachment, skipping... ] > > ---(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 pgman@candle.pha.pa.us | (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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] SELECT DISTINCT performance issue
Hi All, We are testing PostgreSQL 8.0.3 on MS Windows for porting an OLTP system from MS SqlServer. We got a major performance issue which seems to boil down to the following type of query: select DISTINCT ON (PlayerID) PlayerID,AtDate from Player where PlayerID='0' order by PlayerID desc, AtDate desc; The Player table has primary key (PlayerID, AtDate) representing data over time and the query gets the latest data for a player. With enable_seqscan forced off (which I'm not sure if that should be done for a production system), the average query still takes a very long time to return a record: esdt=> explain analyze select DISTINCT ON (PlayerID) PlayerID,AtDate from Player where PlayerID='0' order by PlayerID desc, AtDate desc; Unique (cost=0.00..2507.66 rows=1 width=23) (actual time=0.000..187.000 rows=1 loops=1) -> Index Scan Backward using pk_player on player (cost=0.00..2505.55 rows=8 43 width=23) (actual time=0.000..187.000 rows=1227 loops=1) Index Cond: ((playerid)::text = '0'::text) Total runtime: 187.000 ms It appears that all the 1227 data records for that player were searched, even when doing a backward index scan. I would presume that, after locating the index for the highest AtDate, only the first data record needs to be retrieved. The following summary of tests seems to confirm my observation, as the query returns quickly only after the table was clustered. The tests were done on a quiet system (MS Windows 2000 Server, P4 3.0GHz with Hyperthreading, 1GB Memory, PostgreSQL shared_buffers = 5), starting with a test database before doing a vacuum: set enable_seqscan = off; select Total runtime: 187.000 ms again: Total runtime: 78.000 ms vacuum analyze verbose player; select Total runtime: 47.000 ms again: Total runtime: 47.000 ms reindex table player; select Total runtime: 78.000 ms again: Total runtime: 63.000 ms cluster pk_player on player; select Total runtime: 16.000 ms again: Total runtime: 0.000 ms set enable_seqscan = on; analyze verbose player; select Total runtime: 62.000 ms again: Total runtime: 78.000 ms Previously, we have also tried to use LIMIT 1 instead of DISTINCT, but the performance was no better: select PlayerID,AtDate from Player where PlayerID='0' order by PlayerID desc, AtDate desc LIMIT 1 Any clue or suggestions would be most appreciated. If you need further info or the full explain logs, please let me know. Regards, KC Lau. ps. This problem probably should go to pgsql-performance mailing list, but I have sent this email to pgsql-performance@postgresql.org 3 times over the last 2 days and all of them seemed to have lost, even though I am receiving emails from both lists. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] SELECT DISTINCT performance issue
K C Lau <[EMAIL PROTECTED]> writes: > esdt=> explain analyze select DISTINCT ON (PlayerID) PlayerID,AtDate from > Player > where PlayerID='0' order by PlayerID desc, AtDate desc; > Unique (cost=0.00..2507.66 rows=1 width=23) (actual time=0.000..187.000 > rows=1 loops=1) > -> Index Scan Backward using pk_player on player (cost=0.00..2505.55 > rows=8 > 43 width=23) (actual time=0.000..187.000 rows=1227 loops=1) > Index Cond: ((playerid)::text = '0'::text) > Total runtime: 187.000 ms > It appears that all the 1227 data records for that player were searched, > even when doing a backward index scan. I would presume that, after locating > the index for the highest AtDate, only the first data record needs to be > retrieved. If you'd said LIMIT 1, it indeed would have stopped sooner. Since you did not, it had to scan for more outputs. 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])