Re: [ADMIN] vacuum full problem
Guys, does anyone has any idea? pginfo wrote: Hi, I try to reindex and reindex run ok, but the vacuum still not running. regards, ivan. Antonis Antoniou wrote: pginfo wrote: Hi, I am running pg 7.3.4 on linux red hat 9.0. If I try to execute vacuum full analyze verbose, the pg vacuum some tables and hang after this lines: INFO: --Relation pg_toast.pg_toast_16408-- INFO: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0, Keep/VTL 0/0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: Index pg_toast_16408_index: Pages 1; Tuples 0. CPU 0.00s/0.00u sec elapsed 0.00 sec. After rebooting I can vacuum without any problems. I do not find nothing in my log-file that can point me to this problem. Also the problem comes constantly by me. Any idea or info about this problem? Also I am using pg + java (jboss), but I think vacuum is working normal with it and I have many instalations without this problem. Try to "reindex table pg_toast.pg_toast_16408;" Maybe an index is broken. Many Thanks Antonis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [ADMIN] ER diagram tool for PostgresSQL7.3
Hello They (architects) told me ER is out, UML is in. And they told me also, that something like ER can be done in UML. I think there are some FOSS-Tools for UML (v1.0 or v.2.0)? Regards Oli --- Oli Sennhauser Database-Engineer (Oracle & PostgreSQL) Rebenweg 6 CH - 8610 Uster / Switzerland Phone (+41) 1 940 24 82 or Mobile (+41) 79 450 49 14 e-Mail [EMAIL PROTECTED] Website http://mypage.bluewin.ch/shinguz/PostgreSQL/ Secure (signed/encrypted) e-Mail with a Free Personal SwissSign ID: http://www.swisssign.ch Import the SwissSign Root Certificate: http://swisssign.net/cgi-bin/trust/import smime.p7s Description: S/MIME Cryptographic Signature
Re: [ADMIN] vacuum full problem
On Tue, 11 Nov 2003, Antonis Antoniou wrote: > Guys, does anyone has any idea? Are you sure that vacuum is not just waiting on a lock that some other transaction is holding? I'd suggest checking the contents of pg_locks. ---(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: [ADMIN] vacuum full problem
Hi, I can not be sure if it is not the case. But we are usin this system on a number of servers and it happen only by one. Can I with a pg_locks help detect the query that is running? regards, ivan. Stephan Szabo wrote: > On Tue, 11 Nov 2003, Antonis Antoniou wrote: > > > Guys, does anyone has any idea? > > Are you sure that vacuum is not just waiting on a lock that some other > transaction is holding? I'd suggest checking the contents of pg_locks. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [ADMIN] vacuum full problem
pginfo wrote: Hi, I can not be sure if it is not the case. But we are usin this system on a number of servers and it happen only by one. Can I with a pg_locks help detect the query that is running? No the pg_locks detect only which process handle a lock on a database object. With pg_stat_activity you see the queries running. Also the command ps -eafwww | grep post show you the connection and his state, I bet you have some connection "IDLE in TRANSACTION" Regards Gaeatano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
[ADMIN] RHEL
Im currently on red hat 7.3 running postgres. Everything is running fine. Obviously, Im going to have to upgrade to RHEL 3 in order to receive updates, etc. Does anyone know of any problems with postgres running on RHEL 2.1 or RHEL 3? Thanks, Darryl
Re: [ADMIN] vacuum full problem
On Tue, 11 Nov 2003, pginfo wrote: > Hi, > I can not be sure if it is not the case. > But we are usin this system on a number of servers and it happen only by > one. > Can I with a pg_locks help detect the query that is running? It won't directly tell you what statement is running (although my guess is also that it's probably something like an idle in transaction state backend), but it can tell you if that's the problem probably. You'd see something like: ... 21488 |17057 | | 8613 | AccessShareLock | t ... 21488 |17057 | | 8626 | AccessExclusiveLock | f Which is basically saying that the command in pid 8626 is waiting on the lock that pid 8613 has. ---(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: [ADMIN] ER diagram tool for PostgresSQL7.3
[EMAIL PROTECTED] (Gautam Saha) wrote in message news:<[EMAIL PROTECTED]>... > Hi: > > Is there a ER diagram tool someone can recommend for PostgreSQL? > I should be able to create ER diagram from existing database also > (reverse engineering). > Any open source product would be ideal. > > Thanks, > > Gautam > > > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings I just spent a couple of days on this exact topic. My requirements were reasonablely priced (read cheap) creat and reverse postgres databases. this is what I found without spending alot of money. Data Architect - theKompany $39 DDS-Lite - Chilli Source $299 DeZign for databases - datanamic $229 Enterprise Architect - Sparx Systems $135 Case Studio - Charonware$329 I down loaded a couple of the demos and installed them on a Win 2000 box. You should do the same. good luck. kd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [ADMIN] vacuum full problem
Hi, Thanks for the help. The result by is: acc01=# select * from pg_locks; relation | database | transaction | pid | mode | granted --+--+-+---+-+- 16757 |16976 | | 23169 | AccessShareLock | t 17062 |16976 | | 1372 | AccessShareLock | t 17060 |16976 | | 1372 | AccessShareLock | t | | 116303 | 1372 | ExclusiveLock | t | | 166846 | 23169 | ExclusiveLock | t 16995 |16976 | | 1372 | AccessShareLock | t 17056 |16976 | | 1372 | AccessShareLock | t 17038 |16976 | | 1372 | AccessShareLock | t (8 rows) And only transaction 116303 is the problem. Also it is production system with many transaction/sec and I am looking dor a way to detect what query is in this transaction ( if possible). The system is relativ big and it is dificult to detect this problem only from transacton number, but we will read the code to find the bug. At this point is is clear that we do not have pg bug and it is good news for me. regards, ivan Stephan Szabo wrote: > On Tue, 11 Nov 2003, pginfo wrote: > > > Hi, > > I can not be sure if it is not the case. > > But we are usin this system on a number of servers and it happen only by > > one. > > Can I with a pg_locks help detect the query that is running? > > It won't directly tell you what statement is running (although my guess is > also that it's probably something like an idle in transaction state > backend), but it can tell you if that's the problem probably. > > You'd see something like: > ... > 21488 |17057 | | 8613 | AccessShareLock | t > ... > 21488 |17057 | | 8626 | AccessExclusiveLock | f > > Which is basically saying that the command in pid 8626 is waiting on the > lock that pid 8613 has. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [ADMIN] vacuum full problem
On Tue, 11 Nov 2003, pginfo wrote: > The result by is: > acc01=# select * from pg_locks; > relation | database | transaction | pid | mode | granted > --+--+-+---+-+- > 16757 |16976 | | 23169 | AccessShareLock | t > 17062 |16976 | | 1372 | AccessShareLock | t > 17060 |16976 | | 1372 | AccessShareLock | t > | | 116303 | 1372 | ExclusiveLock | t > | | 166846 | 23169 | ExclusiveLock | t > 16995 |16976 | | 1372 | AccessShareLock | t > 17056 |16976 | | 1372 | AccessShareLock | t > 17038 |16976 | | 1372 | AccessShareLock | t > (8 rows) Is that while the vacuum is running or just a general state that you might run the vacuum in? > And only transaction 116303 is the problem. > Also it is production system with many transaction/sec and I am looking dor a > way to detect what query is in this transaction ( if possible). > The system is relativ big and it is dificult to detect this problem only from > transacton number, but we will read the code to find the bug. Well, you can turn on the statement statistics stuff and/or the statement logging stuff to help you find what the various transactions are doing. I'd wonder if you're maybe not closing a transaction after it's completed its work though and so the locks are sitting around. ---(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: [ADMIN] Trying to pg_restore a 7.1.3 db into 7.3.4 - stalling at 100%
Gaetano, er, shedloads of this read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 methinks thats not a good sign? Shane Gaetano Mendola wrote: Shane Wright wrote: Hi, I'm trying to upgrade our 25Gb database from 7.1.3 to 7.3.4 - pg_dump worked fine, although piping through split to get a set of 1Gb files. But, after a few attempts on using pg_restore to get the data into the new installation I'm having a few problems; basically it restores the first few tables fine (big tables too), but now it's just hanging on one table; using 100% CPU but hardly touching the disk at all (vmstat reports about 50kb every few minutes). what show an strace on that process ? Regards Gaetano Mendola ---(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
[ADMIN] Upgrading to Solaris 9
Good morning, Could you please let me know if Postgres 7.1.3 will run on Solaris 9. If it does, are you aware of any issues. Thank you for your help. Danielle Cossette ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [ADMIN] vacuum full problem
Hi, Stephan Szabo wrote: > On Tue, 11 Nov 2003, pginfo wrote: > > > The result by is: > > acc01=# select * from pg_locks; > > relation | database | transaction | pid | mode | granted > > --+--+-+---+-+- > > 16757 |16976 | | 23169 | AccessShareLock | t > > 17062 |16976 | | 1372 | AccessShareLock | t > > 17060 |16976 | | 1372 | AccessShareLock | t > > | | 116303 | 1372 | ExclusiveLock | t > > | | 166846 | 23169 | ExclusiveLock | t > > 16995 |16976 | | 1372 | AccessShareLock | t > > 17056 |16976 | | 1372 | AccessShareLock | t > > 17038 |16976 | | 1372 | AccessShareLock | t > > (8 rows) > > Is that while the vacuum is running or just a general state that you might > run the vacuum in? > It looks as general state. > > And only transaction 116303 is the problem. > > Also it is production system with many transaction/sec and I am looking dor a > > way to detect what query is in this transaction ( if possible). > > The system is relativ big and it is dificult to detect this problem only from > > transacton number, but we will read the code to find the bug. > > Well, you can turn on the statement statistics stuff and/or the > statement logging stuff to help you find what the various transactions > are doing. I'd wonder if you're maybe not closing a transaction after > it's completed its work though and so the locks are sitting around. I will do it. It is possible to be one not closed transaction, but in this case nobody will be able to modify this table (tables) and the system will stop to respond. The paradox is that the system works well without any problems and on this basis I wrote that (at the beginning) that the problem is by vacuum. How big is the penalty for statistic on? Generaly I think we will be able to found the problem quick. regards, ivan ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [ADMIN] vacuum full problem
On Tue, 11 Nov 2003, pginfo wrote: > Stephan Szabo wrote: > > > On Tue, 11 Nov 2003, pginfo wrote: > > > > > The result by is: > > > acc01=# select * from pg_locks; > > > relation | database | transaction | pid | mode | granted > > > --+--+-+---+-+- > > > 16757 |16976 | | 23169 | AccessShareLock | t > > > 17062 |16976 | | 1372 | AccessShareLock | t > > > 17060 |16976 | | 1372 | AccessShareLock | t > > > | | 116303 | 1372 | ExclusiveLock | t > > > | | 166846 | 23169 | ExclusiveLock | t > > > 16995 |16976 | | 1372 | AccessShareLock | t > > > 17056 |16976 | | 1372 | AccessShareLock | t > > > 17038 |16976 | | 1372 | AccessShareLock | t > > > (8 rows) > > > > Is that while the vacuum is running or just a general state that you might > > run the vacuum in? > > > > It looks as general state. > > > > And only transaction 116303 is the problem. > > > Also it is production system with many transaction/sec and I am looking dor a > > > way to detect what query is in this transaction ( if possible). > > > The system is relativ big and it is dificult to detect this problem only from > > > transacton number, but we will read the code to find the bug. > > > > Well, you can turn on the statement statistics stuff and/or the > > statement logging stuff to help you find what the various transactions > > are doing. I'd wonder if you're maybe not closing a transaction after > > it's completed its work though and so the locks are sitting around. > > I will do it. > It is possible to be one not closed transaction, but in this case nobody will be > able to modify this table (tables) and > the system will stop to respond. The paradox is that the system works well without Not necessarily. People are going to be able to insert/update/delete from the tables (the locks are AccessShareLock) because those don't get a conflicting table lock. They're not going to be able to do things like vacuum full or alter table however because those do. > How big is the penalty for statistic on? I'm not sure, but you can turn it on until you find it and then turn it off again. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [ADMIN] vacuum full problem
Stephan Szabo wrote: > On Tue, 11 Nov 2003, pginfo wrote: > > > Stephan Szabo wrote: > > > > > On Tue, 11 Nov 2003, pginfo wrote: > > > > > > > The result by is: > > > > acc01=# select * from pg_locks; > > > > relation | database | transaction | pid | mode | granted > > > > --+--+-+---+-+- > > > > 16757 |16976 | | 23169 | AccessShareLock | t > > > > 17062 |16976 | | 1372 | AccessShareLock | t > > > > 17060 |16976 | | 1372 | AccessShareLock | t > > > > | | 116303 | 1372 | ExclusiveLock | t > > > > | | 166846 | 23169 | ExclusiveLock | t > > > > 16995 |16976 | | 1372 | AccessShareLock | t > > > > 17056 |16976 | | 1372 | AccessShareLock | t > > > > 17038 |16976 | | 1372 | AccessShareLock | t > > > > (8 rows) > > > > > > Is that while the vacuum is running or just a general state that you might > > > run the vacuum in? > > > > > > > It looks as general state. > > > > > > And only transaction 116303 is the problem. > > > > Also it is production system with many transaction/sec and I am looking dor a > > > > way to detect what query is in this transaction ( if possible). > > > > The system is relativ big and it is dificult to detect this problem only from > > > > transacton number, but we will read the code to find the bug. > > > > > > Well, you can turn on the statement statistics stuff and/or the > > > statement logging stuff to help you find what the various transactions > > > are doing. I'd wonder if you're maybe not closing a transaction after > > > it's completed its work though and so the locks are sitting around. > > > > I will do it. > > It is possible to be one not closed transaction, but in this case nobody will be > > able to modify this table (tables) and > > the system will stop to respond. The paradox is that the system works well without > > Not necessarily. People are going to be able to insert/update/delete from > the tables (the locks are AccessShareLock) because those don't get a > conflicting table lock. They're not going to be able to do things like > vacuum full or alter table however because those do. > Can you point me to any place in docs to read more detailed about locks and statistic ( I have idea, butt also I will to know more if possible). > > How big is the penalty for statistic on? > > I'm not sure, but you can turn it on until you find it and then turn it > off again. regards, ivan. ---(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: [ADMIN] Upgrading to Solaris 9
Danielle Cossette writes: > Could you please let me know if Postgres 7.1.3 will run on Solaris 9. Why don't you try it out? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [ADMIN] Upgrading to Solaris 9
I did and had too many problems and performance issues. Solaris- PostgreSQL just doesn't gel as wel as Linux-PostgreSQL. (ouch) If PostgreSQL were to get retooled to work with threads the way it works between processes today for Solaris or if someone were to find a tweak to make the Solaris scheduler more process-centric than thread-centric (maybe via dispadmin(1)?) then I'm sure Solaris-PG would clobber Linux-PG. I still spin up 7.3.3 on our Sun V480 4CPU, 8GB, 2 internal fibre drives occasionally and our 7.3.3 on RedHat 7.3 with 2.4.20, 2 1.4GHz, 2GB memory and 2 internal U160 kills it. I've tried the many options for UFS and VxFS and EXT3 on Linux still beats it. The database I use on the Sun comes from a pg_dump on the Linux system. But, IMHO Solaris 8 or 9 in comparison to Linux on like hardware, databases, configurations and queries the latter will outperform the former every time. -= IMHO =- The short answer to your question is yes, it will run on Solaris 9. Greg Peter Eisentraut wrote: Danielle Cossette writes: Could you please let me know if Postgres 7.1.3 will run on Solaris 9. Why don't you try it out? -- Greg Spiegelberg Sr. Product Development Engineer Cranel, Incorporated. Phone: 614.318.4314 Fax: 614.431.8388 Email: [EMAIL PROTECTED] Cranel. Technology. Integrity. Focus. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [ADMIN] Upgrading to Solaris 9
Danielle Cossette wrote: Good morning, Could you please let me know if Postgres 7.1.3 will run on Solaris 9. If it does, are you aware of any issues. Seems that solaris is the worst choice for run Postgres. Am I completely wrong ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] Trying to pg_restore a 7.1.3 db into 7.3.4 - stalling at 100%
Shane Wright wrote: Gaetano, er, shedloads of this read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 read(0, "", 4096) = 0 methinks thats not a good sign? I a non sense, I don't have clue why is reading block of 4K from a NULL file descriptor ! Anyone any idea ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [ADMIN] Upgrading to Solaris 9
Sounds like an opportunity for someone at Sun to fund a little research project. Any Sun/Postgresql hackers out there? Any Sun project managers lurking out there? Ray On Tue, Nov 11, 2003 at 01:37:03PM -0500, Greg Spiegelberg wrote: > I did and had too many problems and performance issues. Solaris- > PostgreSQL just doesn't gel as wel as Linux-PostgreSQL. (ouch) > > If PostgreSQL were to get retooled to work with threads the way it > works between processes today for Solaris or if someone were to find > a tweak to make the Solaris scheduler more process-centric than > thread-centric (maybe via dispadmin(1)?) then I'm sure Solaris-PG would > clobber Linux-PG. > > I still spin up 7.3.3 on our Sun V480 4CPU, 8GB, 2 internal fibre > drives occasionally and our 7.3.3 on RedHat 7.3 with 2.4.20, 2 1.4GHz, > 2GB memory and 2 internal U160 kills it. I've tried the many options > for UFS and VxFS and EXT3 on Linux still beats it. The database I use > on the Sun comes from a pg_dump on the Linux system. > > But, IMHO Solaris 8 or 9 in comparison to Linux on like hardware, > databases, configurations and queries the latter will outperform the > former every time. -= IMHO =- > > The short answer to your question is yes, it will run on Solaris 9. > > Greg > > > Peter Eisentraut wrote: > >Danielle Cossette writes: > > > > > >>Could you please let me know if Postgres 7.1.3 will run on Solaris 9. > > > > > >Why don't you try it out? > > > > > -- > Greg Spiegelberg > Sr. Product Development Engineer > Cranel, Incorporated. > Phone: 614.318.4314 > Fax: 614.431.8388 > Email: [EMAIL PROTECTED] > Cranel. Technology. Integrity. Focus. > > > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings -- Ray Ontko [EMAIL PROTECTED] Phone 1.765.935.4283 Fax 1.765.962.9788 Ray Ontko & Co. Software Consulting Services http://www.ontko.com/ ---(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
[ADMIN] cancel <3FB12A96.9090401@bigfoot.com>
This message was cancelled from within Mozilla. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] vacuum full problem
On Tue, 11 Nov 2003, pginfo wrote: > > > It is possible to be one not closed transaction, but in this case nobody will be > > > able to modify this table (tables) and > > > the system will stop to respond. The paradox is that the system works well > > > without > > > > Not necessarily. People are going to be able to insert/update/delete from > > the tables (the locks are AccessShareLock) because those don't get a > > conflicting table lock. They're not going to be able to do things like > > vacuum full or alter table however because those do. > > > > Can you point me to any place in docs to read more detailed about locks and > statistic ( > I have idea, butt also I will to know more if possible). Well, for a list of the lock levels and some examples of where they're used you might want to see: http://www.postgresql.org/docs/7.3/static/explicit-locking.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [ADMIN] Upgrading to Solaris 9
On Tue, 11 Nov 2003 13:37:03 -0500 Greg Spiegelberg <[EMAIL PROTECTED]> wrote: > I did and had too many problems and performance issues. Solaris- > PostgreSQL just doesn't gel as wel as Linux-PostgreSQL. (ouch) > 7.4 "fixes" a lot of hte performance problems we've seen with PG. I had a very strong reason to make PG work well on solaris and after some digging we found that by default, PG was being compiled with no optimization on solaris. That resulted in an AMAZING speed increase - making it comprible to linux. You can get the same effect on 7.3.x by setting CFLAGS=-O2 before running configure. However, establishing connections will not get much of an increase due to solaris' amazingly slow fork(). The thread issue has been beaten to death on -HACKERS. You can also check the -performance lists for the threads I posted about this... oh a couple months ago? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [ADMIN] Trying to pg_restore a 7.1.3 db into 7.3.4 - stalling
> read(0, "", 4096) = 0 > read(0, "", 4096) = 0 > read(0, "", 4096) = 0 > read(0, "", 4096) = 0 > read(0, "", 4096) = 0 > read(0, "", 4096) = 0 > read(0, "", 4096) = 0 > read(0, "", 4096) = 0 > fd 0 is usually stdin, unless the program disconnects stdin. Maybe pg_restore is waiting for input, perhaps a password? -- Jeff Trout <[EMAIL PROTECTED]> http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[ADMIN] Looking for postgresql dba
Hi. We're a hot startup company in Silicon Valley looking for a PostgreSQL DBA. We're open to talking about this as a part-time consulting position or a full time position. Sysadmin experience with Linux/FreeBSD is a huge plus. Please send resumes to jobs (at) everesttech (dot) net Thanks a lot. -w ___ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com ---(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: [ADMIN] ER diagram tool for PostgresSQL7.3
ti, 2003-11-11 kello 05:08, David F. Skoll kirjoitti: > > On Mon, 2003-11-10 at 16:58, Gautam Saha wrote: > > Hi: > > > > Is there a ER diagram tool someone can recommend for PostgreSQL? > > DIA isn't too bad: > > http://www.lysator.liu.se/~alla/dia/ > > This goes from DIA to PostgreSQL: > > http://freshmeat.net/projects/dia2postgres/?topic_id=66%2C259%2C916 > I think tedia2sql is the best of the breed for dia 2 sql transformations you can find it from: http://tedia2sql.tigris.org/ I've used over a year now and I could no longer do without it. > And this goes in the other direction: > > http://freshmeat.net/projects/postgresql_autodoc/?topic_id=66 > Postgresql_autodoc is a nice try, I apologize if it has taken a huge leap since I last took a peek at it but imho it is(was) unusable for anything more than a few tables when doing diagrams. But it has been really good for getting html-table-presentations for relations. I've also looked The Kompanys DA and found it lacking diagrams when reverse engineering a database but a lot better than anything else I've tried for postgres on that purpose. My solution is to keep the diagrams updated so that I don't need reverse engineering. ;) Regards, -- Mauri Sahlberg <[EMAIL PROTECTED]> Claymountain Solutions Oy ---(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: [ADMIN] Upgrading to Solaris 9
On Tue, 11 Nov 2003, Gaetano Mendola wrote: > Danielle Cossette wrote: > > > Good morning, > > > > Could you please let me know if Postgres 7.1.3 will run on Solaris 9. > > If it does, are you aware of any issues. > > Seems that solaris is the worst choice for run Postgres. > > Am I completely wrong ? I thought .org and .info were being run on postgresql/solaris? As another poster pointed out, the Solaris version was building with no optimzation, and it was kinda figured to be in the sysadmin's realm to fix that at build time. You're likely using Solaris' qsort, which was slow in the olden days but I thought it had been sped up recently. If it's been fixed, no worries, as I'm pretty sure Solaris 9 has a qsort that sorts fast with many identical keys. Either way, upgrading to 7.3.4 or 7.4RC2 (for testing, in a couple weeks release...) should provide a very noticable speed increase over 7.1 due to many improvements made since that version. The upgrade to 7.4 might be easier than the upgrade to 7.3 followed by 7.4, as 7.4's pg_dump and pd_dumpall are version aware and can dump a live 7.1.3 database. So, if you wanna try it, just build a test server and: pgsql7.4rc2: pg_dumpall -h production_machine_running_7.1.3 |psql -h testbox_running_7.4.rc2 and see what happens. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[ADMIN] backup restore
(B (B (BHi (BI'm in charge of a linux DB server running postgres (B7.3.2. (BThe OS disk recently died taking the postgres (Binstallation (Bwith it but the data directory of postgres was on a (Bseperate SCSI (Bdisk and is still OK. (B (BI've put in a new OS disk, installed linux on it (Bagain, mounted the data (Bdisk, and installed (Bpostgres up as far as the "make install" stage. (BCan anyone tell me where to go from here to get (Bpostgres to run with the (Bold DB ?? is all the DB structure information (Bstored in the data directory ? (B (BAny help would be appreciated (BColm (B (B~If a kid (Basks where rain comes from, I think a cute thing to tell him is, "God is (Bcrying." And if he asks why God is crying, another cute thing to tell him (Bis, "Probably because of something you did." (B~ (B (B My Website : http://www.angelfire.com/ia/japan/ (BBoomBox : http://www.b00mb0x.org (B (B~
Re: [ADMIN] backup restore
You ought to be able to just start up Postgres pointing to the existing data. So assuming the data directory is /db, just doing 'postmaster -D /db' should work. Provided, of course, you installed the exact version that was there before, with the same user/uid as before. On Nov 11, 2003, at 9:51 PM, Colm De Barra wrote: Hi I'm in charge of a linux DB server running postgres 7.3.2. The OS disk recently died taking the postgres installation with it but the data directory of postgres was on a seperate SCSI disk and is still OK. I've put in a new OS disk, installed linux on it again, mounted the data disk, and installed postgres up as far as the "make install" stage. Can anyone tell me where to go from here to get postgres to run with the old DB ?? is all the DB structure information stored in the data directory ? Any help would be appreciated Colm ~ If a kid asks where rain comes from, I think a cute thing to tell him is, "God is crying." And if he asks why God is crying, another cute thing to tell him is, "Probably because of something you did." ~ My Website :http://www.angelfire.com/ia/japan/ BoomBox :http://www.b00mb0x.org ~ Andrew Rawnsley President The Ravensfield Digital Resource Group, Ltd. (740) 587-0114 www.ravensfield.com ---(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
