Re: [GENERAL] Can't change working directory to C:/Documents and Settings in Windows

2007-07-02 Thread Magnus Hagander
On Sun, Jul 01, 2007 at 10:46:22PM -0300, Jorge Godoy wrote: On Sunday 01 July 2007 22:25:24 Casey Crosbie wrote: Jorge, Thanks for the suggestion. But unfortunately, I tried both \cd C:/Document~1 and just \cd C:/Document~1 and neither worked. Sorry. It should be up to 8 chars:

Re: [GENERAL] postgressqlnot support inwindows 2000

2007-07-02 Thread Dave Page
Magnus Hagander wrote: Yes, but it was not necessarily launched as msiexec. If the file was just double-clicked on, the path to msiexec will be fetched from the registry and not the system PATH. That's the only explanation I can find. Not being installed on Windows 2000 is possible iirc - but

Re: [GENERAL] Is this a bug?

2007-07-02 Thread Albe Laurenz
Harry Jackson wrote: The following sql statement fails because the column user_id does not exist in the users table. =# select user_id from users WHERE username = 'blah'; ERROR: column user_id does not exist LINE 1: select user_id from users WHERE username = 'blah..

Re: [GENERAL] Tables not created in proper schema

2007-07-02 Thread A. Kretschmer
am Mon, dem 02.07.2007, um 11:13:54 +0530 mailte Ashish Karalkar folgendes: Hello All, I am trying to create databse with script. I run this script from root prompt with command $ su - postgres -c 'path to script.sql' In the script I follow following steps 1) create user

Re: [GENERAL] recovery_target_time ignored or recovery alwaysrecovers to end of WAL

2007-07-02 Thread Simon Riggs
On Sun, 2007-07-01 at 21:41 -0700, Jason L. Buberel wrote: I am trying to learn/practice the administrative steps that would need to be taken in a 'fat finger' scenario, and I am running into problems. I am trying to use 'recovery.conf' to set the database state to about 15 minutes ago in

[GENERAL] ERROR: unexpected hash relation size:

2007-07-02 Thread Gerhard Hintermayer
... x should be y I do get these messages one 2 of my servers running mostly on identical data. The servers are unix-based and are running 8.1.8 under linux (Gentoo). On one server the message appears only after vacuum-ing, on the other I had some errors after inserting into the table too

Re: [GENERAL] table disk space usage query?

2007-07-02 Thread Dimitri Fontaine
Le jeudi 28 juin 2007, [EMAIL PROTECTED] a écrit : Hello all - I was looking for a way to find out how much disk space each table is using. As of PostgreSQL 8.1 you can use the following: http://www.postgresql.org/docs/8.1/static/functions-admin.html#FUNCTIONS-ADMIN-DBSIZE Example query to

Re: [GENERAL] shmctl EIDRM preventing startup

2007-07-02 Thread Martijn van Oosterhout
On Sun, Jul 01, 2007 at 10:39:01PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Maybe what is happening is that an entirely unrelated process created a segment with that ID, attached to it, and then it was deleted. I don't know how to check however. AFAIK, EIDRM

[GENERAL] importing limited set of rows/tuples

2007-07-02 Thread cha
Hi All, I have eliminated certain tables while exporting as the size of the data in the tables are huge.Though am having the schema which contains all the tables. Now I want to import limited set of records/rows ( 1000 tuples ) from the eliminated tables. Is this possible? If yes, please

Re: [GENERAL] Tables not created in proper schema

2007-07-02 Thread Ashish Karalkar
Thanks for your replay. I think the problem is with schema not being recognised. following are the line from sql script:(This script is run as a postgres user with password authntication from .pgpass file) ${PG_PATH}/createuser qsweb -S -d -R -l -P -E -q -U postgres ${PG_PATH}/createdb -E

Re: [GENERAL] importing limited set of rows/tuples

2007-07-02 Thread Dimitri Fontaine
Hi, Le lundi 02 juillet 2007, cha a écrit : Now I want to import limited set of records/rows ( 1000 tuples ) from the eliminated tables. Is this possible? If yes, please tell me how to accomplish this? If you have CSV or CSV-like data file format, you can use pgloader with the -C option,

Re: [GENERAL] recovery_target_time ignored or recovery alwaysrecovers to end of WAL

2007-07-02 Thread Jason L. Buberel
Simon, Thanks for the tip. I had assumed that so long as I set 'recovery_target_time' to a value that occurred before the 'fatal commit' and set the 'inclusive' flag to false that I would be able to return to just before the deletion occurred. I'll play with it a bit more and see. I just

Re: [GENERAL] shmctl EIDRM preventing startup

2007-07-02 Thread Michael Fuhr
On Mon, Jul 02, 2007 at 01:05:35PM +0200, Martijn van Oosterhout wrote: If it's installed, this: lsof |grep SYSV Will list all processes attached to a SHM segemtn on the system. I think ipcs can do the same. You can grep /proc/*/maps for the same info. I already tried those; none show

[GENERAL] tables are not listable by \dt

2007-07-02 Thread Rajarshi Guha
Hi, we recently upgraded our Postgres instllation from 7.4 to 8.2 by doing a dump and restore. Howveer after logging into the database (as a user that is not the superuser) and doing \dt I get the error: No relations found But when I do SELECT relname, relpages FROM pg_class ORDER BY

Re: [GENERAL] ERROR: unexpected hash relation size:

2007-07-02 Thread Martijn van Oosterhout
On Mon, Jul 02, 2007 at 11:46:54AM +0200, Gerhard Hintermayer wrote: ... x should be y I do get these messages one 2 of my servers running mostly on identical data. The servers are unix-based and are running 8.1.8 under linux (Gentoo). On one server the message appears only after

Re: [GENERAL] tables are not listable by \dt

2007-07-02 Thread Michael Fuhr
On Mon, Jul 02, 2007 at 10:04:21AM -0400, Rajarshi Guha wrote: Hi, we recently upgraded our Postgres instllation from 7.4 to 8.2 by doing a dump and restore. Howveer after logging into the database (as a user that is not the superuser) and doing \dt I get the error: No relations found

Re: [GENERAL] tables are not listable by \dt

2007-07-02 Thread Tom Lane
Rajarshi Guha [EMAIL PROTECTED] writes: Hi, we recently upgraded our Postgres instllation from 7.4 to 8.2 by doing a dump and restore. Howveer after logging into the database (as a user that is not the superuser) and doing \dt I get the error: No relations found But when I do SELECT

Re: [GENERAL] tables are not listable by \dt

2007-07-02 Thread Mikko Partio
On 7/2/07, Rajarshi Guha [EMAIL PROTECTED] wrote: Hi, we recently upgraded our Postgres instllation from 7.4 to 8.2 by doing a dump and restore. Howveer after logging into the database (as a user that is not the superuser) and doing \dt I get the error: No relations found Are you using the

Re: [GENERAL] tables are not listable by \dt

2007-07-02 Thread Rajarshi Guha
On Jul 2, 2007, at 10:04 AM, Rajarshi Guha wrote: Hi, we recently upgraded our Postgres instllation from 7.4 to 8.2 by doing a dump and restore. Howveer after logging into the database (as a user that is not the superuser) and doing \dt I get the error: No relations found But when I do

Re: [GENERAL] recovery_target_time ignored or recovery alwaysrecovers to end of WAL

2007-07-02 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2007-07-01 at 21:41 -0700, Jason L. Buberel wrote: I am trying to learn/practice the administrative steps that would need to be taken in a 'fat finger' scenario, and I am running into problems. Your example transactions are so large that going

Re: [GENERAL] ERROR: unexpected hash relation size:

2007-07-02 Thread Tom Lane
Gerhard Hintermayer [EMAIL PROTECTED] writes: ... x should be y I do get these messages one 2 of my servers running mostly on identical data. The servers are unix-based and are running 8.1.8 under linux (Gentoo). Update. http://developer.postgresql.org/pgdocs/postgres/release-8-1-9.html

Re: [GENERAL] ERROR: unexpected hash relation size:

2007-07-02 Thread Gerhard Hintermayer
Martijn van Oosterhout wrote: On Mon, Jul 02, 2007 at 11:46:54AM +0200, Gerhard Hintermayer wrote: ... x should be y I do get these messages one 2 of my servers running mostly on identical data. The servers are unix-based and are running 8.1.8 under linux (Gentoo). On one server the message

Re: [GENERAL] ERROR: unexpected hash relation size:

2007-07-02 Thread Gerhard Hintermayer
Tom Lane wrote: Gerhard Hintermayer [EMAIL PROTECTED] writes: ... x should be y I do get these messages one 2 of my servers running mostly on identical data. The servers are unix-based and are running 8.1.8 under linux (Gentoo). Update.

Re: [GENERAL] recovery_target_time ignored or recovery alwaysrecovers to end of WAL

2007-07-02 Thread Jason L. Buberel
Harrumph - I downloaded the latest xlogdump source, and built/installed it against my 8.2.4 source tree. When I execute it however, I am informed that all of my WAL files (either the 'active' copies in pg_xlog or the 'archived' copies in my /pgdata/archive_logs dir) appear to be malformed:

Re: [GENERAL] recovery_target_time ignored or recovery always recovers to end of WAL

2007-07-02 Thread Jason L. Buberel
Some more bits on this: And playing with the date format does not seem to change the outcome (the db is always recovered to the most current state). In this case, I removed the timezone designation 'PDT' from my timestamp, and the db properly figured out that it is running in GMT-7 (pacific)

[GENERAL] How-To: Aggregate data from multiple rows into a delimited list.

2007-07-02 Thread D. Dante Lorenso
This is not a question, but a solution. I just wanted to share this with others on the list in case it saves you a few hours of searching... I wanted to select several rows of data and have them returned in a single record with the rows joined by a delimiter. Turns out this is very easy to

Re: [GENERAL] recovery_target_time ignored or recoveryalwaysrecovers to end of WAL

2007-07-02 Thread Simon Riggs
On Mon, 2007-07-02 at 09:21 -0700, Jason L. Buberel wrote: I downloaded the latest xlogdump source, and built/installed it against my 8.2.4 source tree. When I execute it however, I am informed that all of my WAL files (either the 'active' copies in pg_xlog or the 'archived' copies in my

Re: [GENERAL] recovery_target_time ignored or recoveryalwaysrecovers to end of WAL

2007-07-02 Thread Simon Riggs
On Mon, 2007-07-02 at 11:06 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2007-07-01 at 21:41 -0700, Jason L. Buberel wrote: I am trying to learn/practice the administrative steps that would need to be taken in a 'fat finger' scenario, and I am running into problems.

Re: [GENERAL] Restart after poweroutage

2007-07-02 Thread Tom Lane
Some time ago, Jon Lapham [EMAIL PROTECTED] wrote: Today I had a power outage which upon reboot seems to have done something to cause Postgresql to not restart properly. This has happened to me before: http://archives.postgresql.org/pgsql-general/2006-09/msg00938.php We finally tracked

[GENERAL] Insert speed new post

2007-07-02 Thread Terry Fielder
My first posting stalled because I posted from the wrong email account, here is the new posting, plus some more info: I have a user application use log. Under pg 7.x the system performed fine. In 8.1.9, the insert statements seem to take a long time sometimes, upto several seconds or more.

Re: [GENERAL] recovery_target_time ignored or recoveryalwaysrecovers to end of WAL

2007-07-02 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2007-07-02 at 09:21 -0700, Jason L. Buberel wrote: I downloaded the latest xlogdump source, and built/installed it against my 8.2.4 source tree. When I execute it however, I am informed that all of my WAL files (either the 'active' copies in

Re: [GENERAL] recovery_target_time ignored or recovery always recovers to end of WAL

2007-07-02 Thread Tom Lane
Jason L. Buberel [EMAIL PROTECTED] writes: What worries me is the 'record with zero length', That's just the normal way of detecting end of WAL. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the

Re: [GENERAL] Insert speed new post

2007-07-02 Thread Tom Lane
Terry Fielder [EMAIL PROTECTED] writes: Under pg 7.x the system performed fine. In 8.1.9, the insert statements seem to take a long time sometimes, upto several seconds or more. There is no primary key, but the table is never updated, only inserted. I removed the only index, with no

Re: [GENERAL] recovery_target_time ignored orrecoveryalwaysrecovers to end of WAL

2007-07-02 Thread Simon Riggs
On Mon, 2007-07-02 at 16:32 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2007-07-02 at 09:21 -0700, Jason L. Buberel wrote: I downloaded the latest xlogdump source, and built/installed it against my 8.2.4 source tree. When I execute it however, I am informed that

[GENERAL] Invalid page header

2007-07-02 Thread Poul Møller Hansen
During some time I have had more problems with invalid data in different parts of a PostgreSQL database. Until now it has been pointers to non present clog files and an index file, but now it's in a data file. I'm getting this error when doing a backup: invalid page header in block 5377 of

[GENERAL] General search problem - challenge

2007-07-02 Thread Postgres User
I have a table of around 6,000 places in the world. Everytime my server receives a ping, I'm grabbing the content of an article from an RSS feed. Then I search the article for the presence of any the 6000 terms. A typical article is around 1200 words. I don't need to save the article in a

Re: [GENERAL] General search problem - challenge

2007-07-02 Thread Steve Atkins
On Jul 2, 2007, at 3:36 PM, Postgres User wrote: I have a table of around 6,000 places in the world. Everytime my server receives a ping, I'm grabbing the content of an article from an RSS feed. Then I search the article for the presence of any the 6000 terms. A typical article is around

Re: [GENERAL] Restart after poweroutage

2007-07-02 Thread Jon Lapham
Tom Lane wrote: Some time ago, Jon Lapham [EMAIL PROTECTED] wrote: Today I had a power outage which upon reboot seems to have done something to cause Postgresql to not restart properly. This has happened to me before: http://archives.postgresql.org/pgsql-general/2006-09/msg00938.php We

Re: [GENERAL] Insert speed new post

2007-07-02 Thread Terry Fielder
Responses below. Terry Fielder [EMAIL PROTECTED] Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 Tom Lane wrote: Terry Fielder [EMAIL PROTECTED] writes: Under pg 7.x the system performed fine. In 8.1.9, the insert

Re: [GENERAL] What O/S or hardware feature would be useful for databases?

2007-07-02 Thread Ron Johnson
On 06/18/07 08:05, Merlin Moncure wrote: [snip] That being said, it's pretty clear to me we are in the last days of the disk drive. Oh, puhleeze. Seagate, Hitachi, Fuji and WD aren't sitting around with their thumbs up their arses.In 3-4 years, large companies and spooky TLAs will be

Re: [GENERAL] Experiences of PostgreSQL on-disk bitmap index patch

2007-07-02 Thread Ron Johnson
On 06/25/07 09:58, Tom Lane wrote: [snip] The fly in the ointment is that if the column value is so high cardinality as all that, it's questionable whether you want an index search at all rather than just seqscanning; and it's definite that the index access cost will be only a fraction of the

Re: [GENERAL] [NOVICE] Recursive relationship - preventing cross-index entries.

2007-07-02 Thread Andrew Maclean
Thanks to you all for all your help and comments. I finally ended up creating a trigger to check the constraints. This has the added benefit that more than one constraint can be checked in the one trigger. As to whether it is the best model or not for what I want to do. This question is more

Re: [GENERAL] recovery_target_time ignored or recovery always recovers to end of WAL

2007-07-02 Thread Jason L. Buberel
I now have a working xlogdump, which has allowed me to put together the following steps which I believe demonstrate that the recovery process insists on recovering to the most recent state. Here is the sequence of events shown below: 1. Display contents of 'account_note' table 2. Update note

Re: [GENERAL] Invalid page header

2007-07-02 Thread Michael Harris (BR/EPA)
Hi, I had a similar problem and overcame it by temporarily setting zero_damaged_pages, then doing a full vacuum and re-index on the affected table. The rows contained in the corrupted page were lost but the rest of the table was OK after this. Regards // Mike -Original Message- From:

Re: [GENERAL] recovery_target_time ignored or recovery always recovers to end of WAL

2007-07-02 Thread Jason L. Buberel
Minor correction to the output below - the final table dump actually contained the following - my apologies for the copy/paste error: altos_research=# select * from account_note; account_note_id | customer_account_id | user_id_of_author | creation_date | note

Re: [GENERAL] recovery_target_time ignored or recovery always recovers to end of WAL

2007-07-02 Thread Tom Lane
Jason L. Buberel [EMAIL PROTECTED] writes: ## stopped and started postgres, following syslog output: You seem to have omitted all the interesting details about what you did here; but stopping and starting postgres is certainly not intended to cause it to discard data. There would need to have

Re: [GENERAL] recovery_target_time ignored or recovery always recovers to end of WAL

2007-07-02 Thread Jason L. Buberel
I am now learning that fact, but recall the original scenario that I am trying to mimic: 1. Person accidentally deletes contents of important table. 2. Admin (me) wants to roll back db state to just prior to that deletion. 3. (Me) Assumes that by creating a recovery.conf file and setting the

Re: [GENERAL] recovery_target_time ignored or recovery always recovers to end of WAL

2007-07-02 Thread Jason L. Buberel
I think that I now see the error of my ways. When I shutdown my server, the files under the ./data/ directory still all point to 'now' and not 'a week ago when the backups were taken'. So the recover process insists on bringing the database to a PITR equal to 'now'. Instead, in order to