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
Re: [GENERAL] pg_dump return failed sanity check
Patrick Robin <[EMAIL PROTECTED]> writes: > 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 That's probably an indication that you forgot to delete a function that takes or returns an older custom type that you deleted. Look in pg_proc for a function containing 457690 in proargtypes or prorettype, and delete that tuple (or tuples if more than one). pg_dump oughta be more helpful about where it sees the problem... regards, tom lane
[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] 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
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] 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] 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
[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"...
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
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] 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.
[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
[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
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] 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]
[GENERAL] Zip Code Proximity
Hello All, I know there's been quite a few posts on Zip Code Proximity. Can anyone point me in the right direction to find the code to calulate the distance between two zip codes? I'm basically trying to take a zip code given by a user and return them all of the zip codes within, say 10 miles or 20 miles. I've tried the mailing list search but, they seem to be down or not available. Thanks Andy
[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] 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] 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] 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
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 > 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
Re: [GENERAL] Question about databases in alternate locations...
Richard J Kuhns <[EMAIL PROTECTED]> writes: > Now for the question. What's the reason for using this method, as opposed > to using, say, a system catalog to hold the valid locations? Historical? > Having to stop and restart the backend so it can re-read its environment > seems kind of archaic. Well, there'd be a certain amount of circularity in consulting a table to find out where you can find tables, no? ;-) But you're right, the environment-variable mechanism is pretty grotty. There's been a great deal of discussion already in pg-hackers about how to clean up this and related issues; suggest you consult the archives if you want to get involved with fixing it. regards, tom lane
