Thread: Postgresql performance
Hi Currently we are running Postgresql v7.3.2 on Redhat Linux OS v9.0. We have Windows2000 client machines inserting records into the Postgresql tables via ODBC. After a few weeks of usage, when we do a \d at the sql prompt, there was a duplicate object name, ie it can be a duplicate row of index or table. When we do a \d table_name, it will show a duplication of column names inside the table. It doesnt affect the insertion/updating of the tables, but when we do a pg_dump -Da -t <table_name> <db_name> > /exp/<table_name>.sql, it will not do a proper backup/dump. Do we need to apply any patches or maintenace? Please be informed that NEC Singapore Pte Ltd is now known as NEC Solutions Asia Pacific Pte Ltd. Our address and contact numbers remain. Email: chewtc@ap.nec.com.sg http://www.nec.com.sg/ap Thank you, REgards.
CHEWTC@ap.nec.com.sg writes: > Currently we are running Postgresql v7.3.2 on Redhat Linux OS v9.0. We have > Windows2000 client machines inserting records into the Postgresql tables > via ODBC. > After a few weeks of usage, when we do a \d at the sql prompt, there was a > duplicate object name, ie it can be a duplicate row of index or table. > When we do a \d table_name, it will show a duplication of column names > inside the table. Are you sure you are using 7.3 psql? This sounds like something that could happen with a pre-7.3 (not schema aware) psql, if there are multiple occurrences of the same table name in different schemas. > It doesnt affect the insertion/updating of the tables, but when we do a > pg_dump -Da -t <table_name> <db_name> > /exp/<table_name>.sql, it will not > do a proper backup/dump. I'd wonder about whether you have the right pg_dump, too. regards, tom lane
NEC, > After a few weeks of usage, when we do a \d at the sql prompt, there was a > duplicate object name, ie it can be a duplicate row of index or table. > When we do a \d table_name, it will show a duplication of column names > inside the table. I think the version of PSQL and pg_dump which you are using do not match the back-end database version. Correct this. -- Josh Berkus Aglio Database Solutions San Francisco
Hi The Postgresql package came from the Redhat v9.0 CDROM. I have checked the version using psql --version and it showed v7.3.2 How to check the pg_dump version? Thank you, REgards. Josh Berkus <josh@agliodbs.co To: CHEWTC@ap.nec.com.sg, pgsql-performance@postgresql.org m> cc: Subject: Re: [PERFORM] Postgresql performance 23/10/2003 12:06 AM NEC, > After a few weeks of usage, when we do a \d at the sql prompt, there was a > duplicate object name, ie it can be a duplicate row of index or table. > When we do a \d table_name, it will show a duplication of column names > inside the table. I think the version of PSQL and pg_dump which you are using do not match the back-end database version. Correct this. -- Josh Berkus Aglio Database Solutions San Francisco
Hi The Postgresql package came from the Redhat v9.0 CDROM. I have checked the version using psql --version and it showed v7.3.2 The duplication of table names is in the same schema. How to check the pg_dump version? Thank you, REgards. Tom Lane <tgl@sss.pgh.pa.u To: CHEWTC@ap.nec.com.sg s> cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Postgresql performance 22/10/2003 10:03 PM CHEWTC@ap.nec.com.sg writes: > Currently we are running Postgresql v7.3.2 on Redhat Linux OS v9.0. We have > Windows2000 client machines inserting records into the Postgresql tables > via ODBC. > After a few weeks of usage, when we do a \d at the sql prompt, there was a > duplicate object name, ie it can be a duplicate row of index or table. > When we do a \d table_name, it will show a duplication of column names > inside the table. Are you sure you are using 7.3 psql? This sounds like something that could happen with a pre-7.3 (not schema aware) psql, if there are multiple occurrences of the same table name in different schemas. > It doesnt affect the insertion/updating of the tables, but when we do a > pg_dump -Da -t <table_name> <db_name> > /exp/<table_name>.sql, it will not > do a proper backup/dump. I'd wonder about whether you have the right pg_dump, too. regards, tom lane