RE: [GENERAL] Announce: Postgres Access Control Tool
Hi Mark, > Is there anyway I can get this run under Tcl/Tk on Windows NT? I tried > simply loading ./paco into wish but it failed looking up /usr/ > references. I haven't tested PACO on Windows. But this should work: PACO needs two Tcl/Tk extensions loaded as shared object files: libpgtcl.so - Tcl/Tk Postgres interface libtix.so - widget frameset On Windows this files are LIBPGTCL.DLL and LIBTIX.DLL. The first is part of Postgres and the second can be downloaded from ftp://www.neosoft.com/pub/tcl/sorted/packages-7.6/unknown/tixwin41p6bin.zip You have to edit the PACO source and correct the path. (Search for the "load" command at top of the file.) Please let me know if all has done ok. Gerald
Re: [GENERAL] char(xx) problem
At 4:02 +0200 on 17/12/1999, Gene Selkov, Jr. wrote: > I'm just wondering: are there any alternatives to blank padding? Why > is it done in the first place? That's how fixed-length char type works, since the early days of SQL. You come to expect it, which means that if you use legacy code that has a fixed-width char type, or you decided to use it for its time-saving possibilities, it should behave according to some way which has been established long ago. What I don't get is why, given two bpchar argument, Postgres doesn't just pad the shorter one to the length of the other and then compares, selects and whatnot. Herouth -- Herouth Maoz, Internet developer. Open University of Israel - Telem project http://telem.openu.ac.il/~herouth/personal/
[GENERAL] Cannot index large table in 6.5.3 on Linux
This was originally posted on bugs, to no avail. Maybe someone else in the general mailing list has had similar problems and can shed some light. Basically, the subject say it all. I am trying to index a text field in a somehwhat large table (approx 1GB). We have had this database running for over a year now, and we have never had this problem until upgrading to 6.5.3. Most recently, we were running 6.5.1 and the table indexed fine. We do a lot of inserts on the table each night, so we drop the index first for performance reasons. Since upgrading to 6.5.3, we have not been able to recreate the index (However, an index on a char(1) field and a joint index on (date,integer) both do work -- they generate 2 byte indexes.) When we moved to 6.5.3, we vacuumed the database just to be make sure there were no problems. That worked fine. It's just the creation that seems to be the problem. I have watched the process of creation. It seems to get most or all of the way through the process - it creates an index file about the size of the old one (~75000 bytes). Then we get: webusers=> CREATE INDEX zdaily_id ON daily (id); pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. We have lost the connection to the backend, so further processing is impossible. Terminating. and everything is deleted. The original 6.5.3 install was from the RPM. I have recompiled the database on the machine in question, and still the same result. I have tried both btree and hash indexes, still the same result. At first, the table spanned two files. I moved old data out and shrunk it to one file. Still the same result. I have not been able to cause postmaster to generate a core when it dies. So no I'm stumped. I am running on 1 dual-processor VA-linux machine: Architecture (example: Intel Pentium) : Intel Pentium III 450MHz x2 SMP Operating System (example: Linux 2.0.26 ELF) : Linux version 2.2.7-1.23smp ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 SMP Thu Jul 8 15:23:01 PDT 1999 PostgreSQL version (example: PostgreSQL-6.5.2):PostgreSQL-6.5.3 (from postgresql-6.5.3-1.i386.rpm distributed by www.POstgreSQL.org, then compiled on local machine) Compiler used (example: gcc 2.8.0) : gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) I would appreciate any suggestions on additional possibilities for diagnosis or repair. -- Karl DeBisschop <[EMAIL PROTECTED]> 617.832.0332 (Fax: 617.956.2696) Information Please - your source for FREE online reference http://www.infoplease.com - Your Ultimate Fact Finder http://kids.infoplease.com - The Great Homework Helper Netsaint Plugins Development http://netsaintplug.sourceforge.net
[GENERAL] item descriptions in psql
Hi, I just found a reference to descriptions to functions/tables/...etc. and am now wondering how to add them myself? Joost Roeleveld ps. as an example of what I'm referring to: mydb=> \dd currval description -- sequence current value (1 row) mydb=> \dd mytable--- I want to enter a description for this.. description -- no description (1 row)
[GENERAL] item descriptions in psql
Hi, I just found a reference to descriptions to functions/tables/...etc. and am now wondering how to add them myself? Joost Roeleveld ps. as an example of what I'm referring to: mydb=> \dd currval description -- sequence current value (1 row) mydb=> \dd mytable--- I want to enter a description for this.. description -- no description (1 row)
[GENERAL] Release LRU file
Hi, This is in continuation of mails I sent last week about postgres crashing We are running pg 6.5.1, on Redhar 5.1 with DBI 0.92 and DBD 1.13 on a 512 MB RAM and SCSI machine Our application consists of requests going upto 150 per second on this database with an expected uptime of 24 by 7. Earlier we were getting spinlock messages which we have hoped to sort out by raising number of open files per process to 1024 from the earlier 256 Postgres crashes giving an error message : FATAL 1: Release LRU file : No opened files / no one can be closed. Now can anybody help on how to solve this. Please help Bye, Murali Differentiated Software Solutions
Re: [GENERAL] item descriptions in psql
"J. Roeleveld" wrote: > > Hi, > > I just found a reference to descriptions to functions/tables/...etc. > and am now wondering how to add them myself? > > Joost Roeleveld > > ps. as an example of what I'm referring to: > > mydb=> \dd currval > description > -- > sequence current value > (1 row) > > mydb=> \dd mytable--- I want to enter a description for this.. > description > -- > no description > (1 row) > In the next release, PostgreSQL will have the equivalent of Oracle's COMMENT ON statement to allow for user comments of various database schema objects. Until then, you have to manually insert rows into pg_description with the oid of the target object and the relevant comments: emptoris=> select oid from pg_class where relname = 'webusers'; oid -- 155868 (1 row) emptoris=> insert into pg_description values (155868, 'Webuser Information'); INSERT 182688 1 emptoris=> \dd webusers; description --- Webuser Information (1 row) Hope that helps, Mike Mascari
Re: [GENERAL] Release LRU file
Kimi wrote: > > Hi, > > This is in continuation of mails I sent last week about postgres > crashing > We are running pg 6.5.1, on Redhar 5.1 with DBI 0.92 and DBD 1.13 on a > 512 MB RAM > and SCSI machine > > Our application consists of requests going upto 150 per second on this > database > with an expected uptime of 24 by 7. > Earlier we were getting spinlock messages which we have hoped to sort > out by raising > number of open files per process to 1024 from the earlier 256 > > Postgres crashes giving an error message : FATAL 1: Release LRU file : > No opened files / > no one can be closed. > > Now can anybody help on how to solve this. > > Please help > > Bye, > > Murali > Differentiated Software Solutions We have been running a production server under a somewhat lighter load, and encountered this once. The following conversation took place on the mailing list about a month ago: http://www.PostgreSQL.ORG/mhonarc/pgsql-hackers/1999-11/msg00454.html Mike Mascari <[EMAIL PROTECTED]> writes: > FATAL 1: ReleaseLruFile: No opened files - no one can be closed > This is the first time this has ever happened. I've never seen that either. Offhand I do not recall any post-6.5 changes that would affect it, so the problem (whatever it is) is probably still there. After eyeballing the code, it seems there are only two ways this could happen: 1. the number of "allocated" (non-virtual) file descriptors grew to exceed the number of files Postgres thinks it can have open; 2. something else was temporarily exhausting your kernel's file table space, so that ENFILE was returned for many successive attempts to open a file. (After each one, fd.c will close another file and try again.) #2 seems improbable on an unloaded system, and isn't real probable even on a loaded one, since you'd have to assume that some other process managed to suck up each filetable slot that fd.c released before fd.c could re-acquire it. Once, yes, but several dozen times in a row? So I'm guessing a leak of allocated file descriptors. After grovelling through the calls to AllocateFile, I only see one prospect for a leak: it looks to me like verify_password() neglects to close the password file if an invalid user name is given. Do you use a plain (non-encrypted) password file? If so, I'll bet you can reproduce the crash by trying repeatedly to connect with a username that's not in the password file. If that pans out, it's a simple fix: add "FreeFile(pw_file);" near the bottom of verify_password() in src/backend/libpq/password.c. Let me know if this guess is right... regards, tom lane Hope that helps, Mike Mascari
[GENERAL] Re: [ANNOUNCE] Announce: PostgreSQL-6.5.3 binaries available for Windows NT
Kevin Lo wrote: > > Hi, > > Some people asked me to build PostgreSQL binaries for Windows NT. > The binaries(PostgreSQL-6.5.3) are now available at: > > ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz Great ! > Please go to my page if you want to build it yourself :) > > http://www.freebsd.org/~kevlo/postgres/portNT.html > > The Chinese version is at: > > http://www.freebsd.org/~kevlo/postgres/portNT_Big5.html > And could someone please put a note about them on www.postgresql.org ? I searched it on Sunday for just this and I could only find a link to the last url - the chinese translation ;( --- Hannu
[GENERAL] Announce: PostgreSQL-6.5.3 binaries available for Windows NT
Hi, Some people asked me to build PostgreSQL binaries for Windows NT. The binaries(PostgreSQL-6.5.3) are now available at: ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz Please go to my page if you want to build it yourself :) http://www.freebsd.org/~kevlo/postgres/portNT.html The Chinese version is at: http://www.freebsd.org/~kevlo/postgres/portNT_Big5.html Enjoy! Kevin.
[GENERAL] Re: [ANNOUNCE] Announce: PostgreSQL-6.5.3 binaries available forWindows NT
Hannu Krosing wrote: > Kevin Lo wrote: > > > > Hi, > > > > Some people asked me to build PostgreSQL binaries for Windows NT. > > The binaries(PostgreSQL-6.5.3) are now available at: > > > > ftp://203.79.167.135/pub/postgres-nt-binaries.tar.gz > > Great ! > > > Please go to my page if you want to build it yourself :) > > > > http://www.freebsd.org/~kevlo/postgres/portNT.html > > > > The Chinese version is at: > > > > http://www.freebsd.org/~kevlo/postgres/portNT_Big5.html > > > > And could someone please put a note about them on www.postgresql.org ? > > I searched it on Sunday for just this and I could only find a link to > the last url - the chinese translation ;( Seems you don't read the FAQ :) See http://www.postgresql.org/docs/faq-english.html#1.4 > --- > Hannu - Kevin
[GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS NOT THE SAME AS HEAP' (1070)
Anyone seen this message or know what it means? NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS NOT THE SAME AS HEAP' (1070) Cheers, Ed Loehr
Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)IS NOT THE SAME AS HEAP' (1070)
> Anyone seen this message or know what it means? > > NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS > NOT THE SAME AS HEAP' (1070) Drop index and recreate. Next release will be more specific in error message. -- 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] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)IS NOT THE SAME AS HEAP' (1070)
Bruce Momjian wrote: > > Anyone seen this message or know what it means? > > > > NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS > > NOT THE SAME AS HEAP' (1070) > > Drop index and recreate. Next release will be more specific in error > message. I have no idea *which* index to drop/recreate, and I have hundreds of them. Ouch.
Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
> Bruce Momjian wrote: > > > > Anyone seen this message or know what it means? > > > > > > NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS > > > NOT THE SAME AS HEAP' (1070) > > > > Drop index and recreate. Next release will be more specific in error > > message. > > I have no idea *which* index to drop/recreate, and I have hundreds of them. > Ouch. That will also be fixed. -- 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] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
Bruce Momjian wrote: > > Bruce Momjian wrote: > > > > > > Anyone seen this message or know what it means? > > > > > > > > NOTICE: Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071) IS > > > > NOT THE SAME AS HEAP' (1070) > > > > > > Drop index and recreate. Next release will be more specific in error > > > message. > > > > I have no idea *which* index to drop/recreate, and I have hundreds of them. > > Ouch. > > That will also be fixed. Do you mean to say the offending index will be auto-corrected on the fly? That would be almost as good as preventing the root cause in the first place... Cheers, Ed Loehr
Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
> > That will also be fixed. > > Do you mean to say the offending index will be auto-corrected on the fly? That > would be almost as good as preventing the root cause in the first place... No, it just reports the index name. In 7.1, I think this problem will go away, if not in 7.0. -- 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] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
Bruce Momjian wrote: > > > That will also be fixed. > > > > Do you mean to say the offending index will be auto-corrected on the fly? That > > would be almost as good as preventing the root cause in the first place... > > No, it just reports the index name. In 7.1, I think this problem will > go away, if not in 7.0. Is the problem well-understood? Is there a place where I can read up on it? This kind of instability is painful enough to get me thinking about trying to hack my distribution... Cheers, Ed Loehr
Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
> Bruce Momjian wrote: > > > > > That will also be fixed. > > > > > > Do you mean to say the offending index will be auto-corrected on the fly? That > > > would be almost as good as preventing the root cause in the first place... > > > > No, it just reports the index name. In 7.1, I think this problem will > > go away, if not in 7.0. > > Is the problem well-understood? Is there a place where I can read up on it? This > kind of instability is painful enough to get me thinking about trying to hack my > distribution... I believe it has to do with extra index tuples showing up in the index that are not in the heap. When the count's don't match, the problem is reported. I believe it only happens when the system crashes during an index update. I think it is harmless. To fix it properly requires a very sophisticated write-ahead log that is scheduled for 7.1 in about six months. -- 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] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
Bruce Momjian wrote: > > Is the problem well-understood? Is there a place where I can read up on it? This > > kind of instability is painful enough to get me thinking about trying to hack my > > distribution... > > I believe it has to do with extra index tuples showing up in the index > that are not in the heap. When the count's don't match, the problem is > reported. I believe it only happens when the system crashes during an > index update. That is consistent with my crash experiences this evening. > I think it is harmless. To fix it properly requires a > very sophisticated write-ahead log that is scheduled for 7.1 in about > six months. This problem stops my psql dead in its tracks for related queries even across new sessions. Requires a rebuild of indices before any queries work with the related tables/functions, and since I don't know which one to rebuild (die, horsey, die), I might as well rebuild them all. In production mode, that means stopping user access due to the possibility of violating unique constraints enforced by unique indices. That means downtime, which would makes moi persona non grata. But maybe my assumptions are incorrect or I didn't understand what you mean by harmless? Cheers, Ed Loehr
Re: [GENERAL] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
> > I think it is harmless. To fix it properly requires a > > very sophisticated write-ahead log that is scheduled for 7.1 in about > > six months. > > This problem stops my psql dead in its tracks for related queries even across new > sessions. Requires a rebuild of indices before any queries work with the related > tables/functions, and since I don't know which one to rebuild (die, horsey, die), I > might as well rebuild them all. In production mode, that means stopping user access >due > to the possibility of violating unique constraints enforced by unique indices. That > means downtime, which would makes moi persona non grata. But maybe my assumptions >are > incorrect or I didn't understand what you mean by harmless? Maybe other people can chime in here. Why are you getting the inital crashes? -- 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] Index pg_proc_prosrc_index: NUMBER OF INDEX' TUPLES (1071)ISNOT THE SAME AS HEAP' (1070)
Bruce Momjian wrote: > > > I think it is harmless. To fix it properly requires a > > > very sophisticated write-ahead log that is scheduled for 7.1 in about > > > six months. > > > > This problem stops my psql dead in its tracks for related queries even across new > > sessions. Requires a rebuild of indices before any queries work with the related > > tables/functions, and since I don't know which one to rebuild (die, horsey, die), I > > might as well rebuild them all. In production mode, that means stopping user >access due > > to the possibility of violating unique constraints enforced by unique indices. >That > > means downtime, which would makes moi persona non grata. But maybe my assumptions >are > > incorrect or I didn't understand what you mean by harmless? > > Maybe other people can chime in here. Why are you getting the inital > crashes? I don't know. My only suspect right now is that it may be the residual effects of having parameter mismatches in 'RAISE' statements in PL/pgSQL. In any event, I'll try to collect some data for troubleshooting... Cheers, Ed Loehr
