Re: [GENERAL] upgrade to 7.0 using RPM
Paul Condon wrote: I am attempting to migrate to 7.0 using the RPMs that were recently announced. I use rpm -Uvh file name During the processing of several of the RPMs I get a message: /sbin/ldconfig: warning: /usr/lib/libnewt.so.0.50 is not a symlink What does this mean? Should I be worried? I also got the same warning when I removed these with "rpm -e ..." This is occuring when the postinstall and postuninstall scripts re-call ldconfig. If you simply run /sbin/ldconfig, you may see the same message. It is not a PostgreSQL RPM problem, as libnewt is not a part of our RPM set. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[GENERAL] pg_dump return failed sanity check
Hi, When I try to use pg_dump, I get this error. Can it have something to do with a custom type I added. I made sure I added the input/output functions and comparision functions for sorting and queries. The type works fine in SQL queries in general. pg_dump -s scm \connect - d23adm failed sanity check, type with oid 457690 was not found Thanks Patrick -- Patrick Robin [EMAIL PROTECTED] Walt Disney Feature Animation 500 South Buena Vista Street Burbank,California 91521-4817
[GENERAL] Re: PostgreSQL General Digest V1 #156
I don't know the internals of PostgreSQL, but logically INTERSECT is a join, but with an automatic default generation of the WHERE clause. As such, there should not be any difference in performance on tables that are large enough to mask small differences in the time it takes to parse the command. If you have an example which shows that there is a big difference in performance in PostgreSQL, this should be looked at by the relavant hackers, IMHO. Concerning INTERSECT vs. join: SQL is a turgid, goofy, redundant language. Somebody should invent a better one. Maybe this should be put on the TODO list of the PostgreSQL organization. Subject: Re: Am I really stupid??? Date: Wed, 17 May 2000 10:57:45 +0200 From: Dragos Stoichita [EMAIL PROTECTED] To: [EMAIL PROTECTED] Original message from: Raul Chirea Anyway, try to learn some SQL bases before asking that kind of things (especially the "join between two or more tables" notion and what is an "index" and how to use it) ! You'll save a lot of time, yours and other's. 1) I intensively use indexes 2) I already used joins but my problem is a lot more complicated than this one, I have to do around 20 intersects between very complicated SQL queries, so rewriting this in joins is very difficult if not near impossible. 3) I think I have given some very strong arguments in my message. I have to write a database system for an online employment site and there is a search with more than 20 criteria. There should be around 1 candidates after 1 year, but I prefer to be sure the search is very fast with 10 or 100 so that in the future there will be no problems. For each one of the search criteria I have done simple tables with 2 columns, one being the index and the other an integer indicating the candidate identifier. After having done multiple selects, I need to do an intersect. Of course I can't say it is impossible to write the same thing in joins, but believe me it would be a lot slower, here's my idea: Each of the selects returns around 2000 integers. I have a 400 Mhz pc for the development, but the final machine will be an IBM Netfinity server with several pentium 3 processors. What I do is a very high quality work and the server must be able to handle a huge demand. Now of course every people in this forum will tell me to rewrite the query in a join, because I gave a simple example, but I could tell you a SQL request that's near 1 page long, between multiple intersects and unions. Now that's ONE thing that I think nobody here will be able to excuse: Sorting integers on today's 400+ Mhz pc's, especially 1 ones, is really fast. Doing an unique on sorted integers is really fast too. Doing an intersect on sorted, unique integers is really fast. So intersecting 2000x2000x3000x2000x5000 on today's 400+ Mhz pc's should always take less than 1 second (a lot less). Nobody really answered my question. I did not ask you to tell me how to rewrite my question, because I already know that, don't think I do not read the docs, tutorials, etc. I need this fast intersect because if I did not have it the complexity of the problem would have been multiplied by at least a factor of 10 believe me.
[GENERAL] line type
hi, we're looking at migrating from ORACLE to postgres in the very near future and we've run into a small problem. there's a data type defined "LINE". we have named one of our tables as "LINE" also and it would require a great deal of code changes to rename that table. is it possible to simply "turn off" the line type? any help is appreciated. thanks, mikeo
[GENERAL] advice on holding mail
Dear All, I'll be away for a few weeks... can anyone tell me how to switch my mail from this mailing list off for the duration, and how to switch it to digest mode on my return? Thanks much Rob
[GENERAL] BLCKSZ
If I set the block size from 8k to 16k by editing /include/config.h, then all tuples will take up 16k on disk? If true, it just wastes lots of disk space if you are really not going to be storing more than 8k in most tuples? -- Robert B. Easter [EMAIL PROTECTED]
Re: [GENERAL] BLCKSZ
On Wed, May 17, 2000 at 02:53:17PM -0400, Robert B. Easter wrote: If I set the block size from 8k to 16k by editing /include/config.h, then all tuples will take up 16k on disk? If true, it just wastes lots of disk space if you are really not going to be storing more than 8k in most tuples? Currently, more than one tuple can be stored in a block, it's just that any one tuple cannot be stored in more than one block: i.e. tuples cannot span blocks, so the BLKSZ sets the maximum tuple size. Clear? Ross -- Ross J. Reedstrom, Ph.D., [EMAIL PROTECTED] NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
[GENERAL] initdb and exit_nicely...
I believe there is a bug, or at least a not very nice feature in initdb. If initdb does not succeed, it attempts to "exit_nicely". By default this involved deleting the $PGDATA directory!! So if you have put other things in you $PGDATA directory or (as in my case) you attempt to create a database in an existing directory that contains lots of stuff that you really, really wanted to keep, and initdb fails, initdb very "nicely" deletes them for you if it fails. It seems like it would be a whole lot "nicer" if initdb only deleted the files that it attempted to create OR if the default was not to delete anything. In any case, I have changed the default on my installation to NEVER "clean up" for me. Jeff Collins
[GENERAL] why so big?
I've just created a new database and I am wondering... Why are all sequence files 8K? They're one freaking int. How come the indexes are so large? They tend to be larger than the database files themselves. In one case I have a 16K index on an empty table. -rw---1 postgres postgres 0 May 11 19:12 category -rw---1 postgres postgres 16384 May 11 19:13 category_parent_key -rw---1 postgres postgres 16384 May 11 19:12 category_pkey -rw---1 postgres postgres8192 May 17 03:35 message -rw---1 postgres postgres8192 May 12 13:26 message_id_seq -rw---1 postgres postgres 16384 May 17 03:35 message_o_key -rw---1 postgres postgres 16384 May 17 03:35 message_pkey -rw---1 postgres postgres 16384 May 17 03:35 message_p_key
Re: [GENERAL] why so big?
-Original Message- From: Joseph Shraibman [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, May 17, 2000 4:33 PM Subject: [GENERAL] why so big? I've just created a new database and I am wondering... Why are all sequence files 8K? They're one freaking int. How come the indexes are so large? They tend to be larger than the database files themselves. In one case I have a 16K index on an empty table Overhead! I think you will find that 8K is the smallest file that can be allocated if you add one record to a table, the index isn't going to get any bigger for a while until it fills up the 16K.
Re: [GENERAL] 7.0 psql, readline and history.
Jeffery Collins writes: Wanna' bet? Perhaps I had an even older version? FWIW, it turns out that mine is actually 2.2.1. I don't know alot about the readline library, but perhaps it would be sufficient to check for the presence of "using_history" in the library and not bother to check for the presence of history.h? After reviewing the old code, this is seemingly what it did. The history functions are then used without declaring them. I should probably squeeze a patch for this into 7.0.1. Of course, updating readline to a "sane" version is a valid workaround as well. (And believe me, there are plenty of "insane" versions out there that we already had to put up with.) -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
Re: [GENERAL] initdb and exit_nicely...
Jeffery Collins writes: It seems like it would be a whole lot "nicer" if initdb only deleted the files that it attempted to create OR if the default was not to delete anything. Okay, I could go for the former. What do others think? -- Peter Eisentraut Sernanders väg 10:115 [EMAIL PROTECTED] 75262 Uppsala http://yi.org/peter-e/Sweden
[GENERAL] getting libperl.so
I'd like to write some functions in embedded perl. I have installed Mandrake from the RPMS recommended on this list a few days ago ( They worked great, by the way). I have also downloaded the source so I can compile plperl.so. But I can't because appearantly libperl.so is not configured properly on my machine. I'm using Mandrake 7.0, and the only copy of libperl.so that I can find is in: /usr/lib/apache (thanks to the mod-perl rpm). How do I get libperl.so so I can compile plperl? Thanks, Travis Bauer | CS Grad Student | IU |www.cs.indiana.edu/~trbauer
Re: [GENERAL] initdb and exit_nicely...
Peter Eisentraut [EMAIL PROTECTED] writes: It seems like it would be a whole lot "nicer" if initdb only deleted the files that it attempted to create OR if the default was not to delete anything. Okay, I could go for the former. What do others think? It'd be a bit of a pain but I can see the problem. You certainly shouldn't delete the $PGDATA directory itself unless you created it, IMHO. Doing more than that would imply that initdb's cleanup function would have to know the list of files/subdirectories that normally get created during initdb, so as to remove only those and not anything else that might be lying around in the directory. That'd be a considerable maintenance headache since most of said files are not created directly by the script... BTW, what about collisions? Suppose the reason the initdb fails is that there's already a (bogus) pg_log, or some such --- is the script supposed to know not to delete it? That strikes me as way too difficult, since now the script has to know not only which files get created but exactly when. A slightly more reasonable example is where the admin has already inserted his own pg_hba.conf in the directory; would be nice if initdb didn't overwrite it (nor delete it on failure), but I'm not sure it's worth the trouble. Something that would be a lot simpler is to refuse to run at all if the $PGDATA dir exists and is nonempty ;-) regards, tom lane
Re: [GENERAL] Does Psql support Chinese?
I want to build a database in chinese. But when I input chinese in the linux psql client , it doent's display well. So how can I solve it? Does your cat command show your Chinese texts correctly? If not, that might not be a PostgreSQL problem. BTW, what kind of encoding are you using for your Chinese texts? -- Tatsuo Ishii
Re: [GENERAL] getting libperl.so
Travis Bauer [EMAIL PROTECTED] writes: compile plperl.so. But I can't because appearantly libperl.so is not configured properly on my machine. I'm using Mandrake 7.0, and the only copy of libperl.so that I can find is in: /usr/lib/apache (thanks to the mod-perl rpm). Probably your main perl installation is not using a shared libperl? You may have to pull down the perl source distribution and configure/compile/install it yourself. Should be pretty painless, really (certainly nothing to fear if you can build Postgres from source ;-)). Don't forget to say "yes" when the configure script asks you if you want a shared libperl. You can probably default all the other answers, except maybe for the location you want the perl directory tree placed ... regards, tom lane PS: be careful not to lose any Perl modules you may have installed that don't come with the source distribution.
Re: [GENERAL] initdb and exit_nicely...
A slightly more reasonable example is where the admin has already inserted his own pg_hba.conf in the directory; would be nice if initdb didn't overwrite it (nor delete it on failure), but I'm not sure it's worth the trouble. I am inclined to leave it as is too. I can imagine many bug reports if that directory is not flushed on failure. -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[GENERAL] RE: 7.0 psql, readline and history.
Thanks Jeff. I'm the guy that started that thread. Been meaning to get back to the problem but had other issues on the project. Now I know what to do next. Appreciate your posting the solution. -=michael=- * * Michael S. Kelly * 4800 SW Griffith Dr., Ste. 202 * Beaverton, OR 97005 USA * voice: (503)644-6106 x122 fax: (503)643-8425 * [EMAIL PROTECTED] * http://www.axian.com/ * *Axian: Software Consulting and Training * -Original Message- From: Jeffery Collins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 16, 2000 4:58 PM To: [EMAIL PROTECTED] Subject: 7.0 psql, readline and history. I saw a note a few days ago about the arrow keys not working in psql in 7.0. As I recall the answer was to make sure the configure script could find "readline.h". I had the same problem as the original questioner, and attempted the suggested fix. The fix did allow configure to find "readline.h" as well as "readline/readline.h", but the problem wasn't fixed. After some investigation (i.e. reading the source), I determined the real problem was my version of readline. It *appears* to me that 7.0 requires readline version 4.1 in order for the readline history features to work, whereas 6.5.3 was happy with an earlier version. When I updated my version of readline, the readline history functions started working. I hope this isn't a repeat of earlier mail on this topic (I only joined the mailing list about a week ago), and I hope it helps people with the same problem that I had. Jeff Collins
Re: [GENERAL] getting libperl.so
Tom Lane wrote: Travis Bauer [EMAIL PROTECTED] writes: compile plperl.so. But I can't because appearantly libperl.so is not configured properly on my machine. I'm using Mandrake 7.0, and the only copy of libperl.so that I can find is in: /usr/lib/apache (thanks to the mod-perl rpm). Probably your main perl installation is not using a shared libperl? You may have to pull down the perl source distribution and configure/compile/install it yourself. Should be pretty painless, really (certainly nothing to fear if you can build Postgres from source ;-)). Don't forget to say "yes" when the configure script asks you if you want a shared libperl. You can probably default all the other answers, except maybe for the location you want the perl directory tree placed ... regards, tom lane PS: be careful not to lose any Perl modules you may have installed that don't come with the source distribution. or 'ar -a libperl.a' into a directory then gcc the resulting .o files into a single libperl.so You will have to run ldconfig and tweak the makefile because perl won't know that .so is available, but I've used this just fine on RedHat, which also doesn't include a shared libperl. Karl DeBisschop www.infoplease.com
Re: [GENERAL] getting libperl.so
Tom Lane wrote: Karl DeBisschop [EMAIL PROTECTED] writes: or 'ar -a libperl.a' into a directory then gcc the resulting .o files into a single libperl.so That will only work on platforms where code is compiled position-independent by default. Yes. Such seems to be the case for RedHat (and I believe all other x86 linux) In any case, it won't persuade the existing plperl Makefile that libperl is a .so file, because the Makefile looks at the build-time config data that's recorded in some Perl module or other :-( I thought I had mentioned that as well - but the mods to the makefile are not difficult - just lop out the part where Makefile.PL checks for the .so - you just manually installed it, so you know it's there. And then make sure the .so is referenced on the subsequent gcc invocation Karl
