pg_ctl problem

[Alexander Cohen]

(sorry for the double post if there is one - i sent the mail to the
lisyt from the wrong address)

Hi,

Im passing this in the commmand line to start up the PostgreSQL server:

../pg_ctl start -w -D /Volumes/GROUCH\ 2/Database3

but its always giving me this error:

../postmaster: invalid argument: "2/Database3"

so i tried passing this: ( added quotes to the problematic database
path )

../pg_ctl start -w -D "/Volumes/GROUCH\ 2/Database3"

and i still get the same error.

Can i not pass a path with spaces in it?
How should i pass this command to the command line in order to get the
server up and running?

thanks!

--
Alexander Cohen
http://www.toomuchspace.com
[phone]
[phone]
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to ma*******@postg resql.org)

[Jim Seymour]

Alexander Cohen <al**@toomuchsp ace.com> wrote:

[snip]
so i tried passing this: ( added quotes to the problematic database
path )

./pg_ctl start -w -D "/Volumes/GROUCH\ 2/Database3"

and i still get the same error.

Can i not pass a path with spaces in it?
Possibly with enough "escaping," you could do it. pg_ctl is itself a
shell script. So when it expands the argument to the -D switch, at
least one set of quotes will be lost. (Btw: The back-slash wasn't
really necessary.)
How should i pass this command to the command line in order to get the
server up and running?

You might be able to find some combination of escape sequences,
repeated escape sequences, etc., etc., to get it to work. But then, if
pg_ctl is subsequently changed to alter the way that argument is
processed: You're screwed.

I hate to answer a question with a question, but if ever there was a
case where doing so would appear legitimate, this, IMO, would have to
be it. So... Why in God's name are you trying to do this? Why not
just get rid of the space and save yourself the current, and possibly
future, grief?

--
Jim Seymour | Spammers sue anti-spammers:
js******@LinxNe t.com | http://www.LinxNet.com/misc/spam/slapp.php
http://jimsun.LinxNet.com | Please donate to the SpamCon Legal Fund:
| http://www.spamcon.org/legalfund/

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postg resql.org so that your
message can get through to the mailing list cleanly

[Alexander Cohen]

> I hate to answer a question with a question, but if ever there was a

case where doing so would appear legitimate, this, IMO, would have to
be it. So... Why in God's name are you trying to do this? Why not
just get rid of the space and save yourself the current, and possibly
future, grief?

because this is an app for users and they might have spaces in their
path.

Alex
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Jim Seymour]

Alexander Cohen <al**@toomuchsp ace.com> wrote:

[snip]

Why not
just get rid of the space and save yourself the current, and possibly
future, grief?

because this is an app for users and they might have spaces in their
path.

*Users* are starting up postmaster? *shrug* ISTM you're left with the
following choices:

1. Work at it until you've figured-out just the right
combination of shell escapes to get the path though pg_ctl's
"cooking." The prior caveat applies: If pg_ctl is modified
relative to that switch's argument handling, it'll break again.

2. Modify pg_ctl so the argument, in all its processing, is
preserved with embedded spaces. Of course, the next release of
pgsql would require re-doing it if pg_ctl is changed.

3. Talk pgsql's developers into fixing the "problem."
(If you fix it, as in #2, you could submit a patch.)

4. Tell your users not to do that. Spaces in pathnames are
pure evil anyway. A problem generally only found with end-users
using (only) point-n-drool tools.

Personally, looking at pg_ctl's code, I think #1 is exceedingly
unlikely to succeed. #2 (and, by extension, #3) looks kind of
iffy, too.

Good luck.

--
Jim Seymour | Spammers sue anti-spammers:
js******@LinxNe t.com | http://www.LinxNet.com/misc/spam/slapp.php
http://jimsun.LinxNet.com | Please donate to the SpamCon Legal Fund:
| http://www.spamcon.org/legalfund/

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Alexander Cohen]

> *Users* are starting up postmaster? *shrug* ISTM you're left with the

following choices:
Users of the application that can start up the postmaster of course.
Some poeple dont like using the command line. :P

1. Work at it until you've figured-out just the right
combination of shell escapes to get the path though pg_ctl's
"cooking." The prior caveat applies: If pg_ctl is modified
relative to that switch's argument handling, it'll break again.

2. Modify pg_ctl so the argument, in all its processing, is
preserved with embedded spaces. Of course, the next release of
pgsql would require re-doing it if pg_ctl is changed.

3. Talk pgsql's developers into fixing the "problem."
(If you fix it, as in #2, you could submit a patch.)

4. Tell your users not to do that. Spaces in pathnames are
pure evil anyway. A problem generally only found with end-users
using (only) point-n-drool tools.

Personally, looking at pg_ctl's code, I think #1 is exceedingly
unlikely to succeed. #2 (and, by extension, #3) looks kind of
iffy, too.

im probably going to try all of them until i find something that
succeeds. I might just pass it all to the postmaster directly.

thanks!
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Siew Hui, Wong]

Postgresql 7.3.4
RH 8.0

Hello all,

The client requirements are that from the website(a coldfusionmx app), they
could backup and restore the database from the list of backups available.
All i've given to work on is just that to allow user to select backup to
restore and also to allow user to perform a manual database backup.

Here's how the "manual backup" process goes. When user clicks on "Backup
Database Now", a row is inserted to a table (app_dbactionb) to trigger off
the pg_dump. Problem is an error msg appeared when i insert test data into
table:

"standard in must be a tty."

Below are the functions and trigger concerned:
############### ############### #####
CREATE TRIGGER autobackup
AFTER INSERT ON app_dbactionb
FOR EACH ROW
EXECUTE PROCEDURE initbackup ();
CREATE FUNCTION initbackup () RETURNS "trigger" AS '
begin
perform Backup ();
return NEW;
end;
' LANGUAGE 'plpgsql';
CREATE FUNCTION backup () RETURNS integer
AS '
system("/home/postgres/testbackupdb");
return 0;
'LANGUAGE plperlu;
############### ############### #####

Below is the testbackupdb (chmod 777, owner postgres):

#!/bin/bash
#File is named according to abbreviation of week name (Sun...Sat)
#e.g. nsvm_Mon_2004.d b

backupdate=`dat e +%a_%Y`
/bin/su - postgres -c "/usr/local/pgsql/bin/pg_dump -f
/home/postgres/nsvm_$backupdat e.db nsvm"
echo "Backup at `date` :
nsvm_$backupdat e.db">>/home/postgres/nsvm_backup_log
I really appreciate any form of advice and feedback on this error. Please
let me know too, if there are more efficient ways to allow user to backup
from a webpage :) Thank you all for the time.
Best regards,
siew hui

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Tom Lane]

js******@LinxNe t.com (Jim Seymour) writes:

2. Modify pg_ctl so the argument, in all its processing, is
preserved with embedded spaces. Of course, the next release of
pgsql would require re-doing it if pg_ctl is changed. 3. Talk pgsql's developers into fixing the "problem."
(If you fix it, as in #2, you could submit a patch.)

It did look to me like pg_ctl was a few quotes shy of a load. If
someone wants to submit a patch to fix this, it'd be accepted.

regards, tom lane

---------------------------(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

[Siew Hui, Wong]

Hi again,

Is it possible that there is a permission problem etc that don't allow
plperlu function that calls a pg_dump command? I am still stumped, trying to
solve the problem of "Standard in must be a tty" whenever i triggered the
plperlu function :(

Any advice is greatly appreciated. Thank you in advance.

best regards,
siew hui
----- Original Message -----
From: "Siew Hui, Wong" <sh****@sebasas ia.com>
Sent: Friday, April 09, 2004 11:27 AM
Subject: [GENERAL] Error in function to pg_dump: Standard in must be a tty

Postgresql 7.3.4
RH 8.0

Hello all,

The client requirements are that from the website(a coldfusionmx app), they could backup and restore the database from the list of backups available.
All i've given to work on is just that to allow user to select backup to
restore and also to allow user to perform a manual database backup.

Here's how the "manual backup" process goes. When user clicks on "Backup
Database Now", a row is inserted to a table (app_dbactionb) to trigger off
the pg_dump. Problem is an error msg appeared when i insert test data into
table:

"standard in must be a tty."

Below are the functions and trigger concerned:
############### ############### #####
CREATE TRIGGER autobackup
AFTER INSERT ON app_dbactionb
FOR EACH ROW
EXECUTE PROCEDURE initbackup ();
CREATE FUNCTION initbackup () RETURNS "trigger" AS '
begin
perform Backup ();
return NEW;
end;
' LANGUAGE 'plpgsql';
CREATE FUNCTION backup () RETURNS integer
AS '
system("/home/postgres/testbackupdb");
return 0;
'LANGUAGE plperlu;
############### ############### #####

Below is the testbackupdb (chmod 777, owner postgres):

#!/bin/bash
#File is named according to abbreviation of week name (Sun...Sat)
#e.g. nsvm_Mon_2004.d b

backupdate=`dat e +%a_%Y`
/bin/su - postgres -c "/usr/local/pgsql/bin/pg_dump -f
/home/postgres/nsvm_$backupdat e.db nsvm"
echo "Backup at `date` :
nsvm_$backupdat e.db">>/home/postgres/nsvm_backup_log
I really appreciate any form of advice and feedback on this error. Please
let me know too, if there are more efficient ways to allow user to backup
from a webpage :) Thank you all for the time.
Best regards,
siew hui

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

"Siew Hui, Wong" <sh****@sebasas ia.com> writes:

Is it possible that there is a permission problem etc that don't allow
plperlu function that calls a pg_dump command? I am still stumped, trying to
solve the problem of "Standard in must be a tty" whenever i triggered the
plperlu function :(

I'd guess that that complaint is coming from /bin/su because it's not
finding anyplace to ask for the password. But why are you trying to su
to postgres at all? Anything the backend launches will be running as
the postgres user to start with.

The entire project seems fatally flawed anyway ... you can't seriously
think it's a good idea to launch a complete-database pg_dump after every
row insertion. Quite aside from the performance implications, you
won't even manage to achieve what you presumably want, because the
pg_dump run is executed before the row-inserting transaction commits,
and so it won't include that new row.

I'd counsel thinking about launching periodic pg_dumps via a cron job,
or some such, instead. Also see the various replication tools that are
available.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Siew Hui, Wong]

hi tom,

Based on your suggestion, I deleted the fragment "/bin/su - postgres -c"
from the bash script and it worked! Thanks for the pointer.

But for the way i go about fulfilling the user's reqs, I apologised if it
didn't come out clearly in the first post :) Let me try again.

A broker firm, the user needs to update the prices etc daily. If any mistake
happen in the updates, they would want to revert to the latest backup and
redo.

Hence, i am to create something that allows the user (from a webpage) to
manually backup and/or restore database of any backup date. So, the page
shows a list of backups for the last 7 days to be selected for restorating
and also a button for there-and-then manual backup of database.

For daily auto backup.i've already scheduled cronjob and it went well.

This is the new script that i've implemented which i have 'chown' to
postgres:

#!/bin/bash
#File is named according to abbreviation of week name (Sun...Sat)
#e.g. nsvm_Mon_2004.d b

backupdate=`dat e +%a_%Y`
/usr/local/pgsql/bin/pg_dump -f /home/postgres/nsvm_$backupdat e.db
excensio ## <--- the change
echo "Backup at `date` :
nsvm_$backupdat e.db">>/home/postgres/nsvm_backup_log
Again, i appreciate any suggestions for more efficient ways. Thanks again !
best regards,
siew hui

----- Original Message -----
From: "Tom Lane" <tg*@sss.pgh.pa .us>
Sent: Monday, April 12, 2004 1:27 PM
Subject: Re: [GENERAL] Error in function to pg_dump: Standard in must be a
tty

"Siew Hui, Wong" <sh****@sebasas ia.com> writes:

Is it possible that there is a permission problem etc that don't allow
plperlu function that calls a pg_dump command? I am still stumped, trying to solve the problem of "Standard in must be a tty" whenever i triggered the plperlu function :(

I'd guess that that complaint is coming from /bin/su because it's not
finding anyplace to ask for the password. But why are you trying to su
to postgres at all? Anything the backend launches will be running as
the postgres user to start with.

The entire project seems fatally flawed anyway ... you can't seriously
think it's a good idea to launch a complete-database pg_dump after every
row insertion. Quite aside from the performance implications, you
won't even manage to achieve what you presumably want, because the
pg_dump run is executed before the row-inserting transaction commits,
and so it won't include that new row.

I'd counsel thinking about launching periodic pg_dumps via a cron job,
or some such, instead. Also see the various replication tools that are
available.

regards, tom lane

---------------------------(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