Thread: pg_ctl problem
(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 (819) 348-9237 (819) 432-3443
Alexander Cohen <alex@toomuchspace.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: jseymour@LinxNet.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/
> 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
Alexander Cohen <alex@toomuchspace.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:
jseymour@LinxNet.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/
> *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!
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.db
backupdate=`date +%a_%Y`
/bin/su - postgres -c "/usr/local/pgsql/bin/pg_dump -f
/home/postgres/nsvm_$backupdate.db nsvm"
echo "Backup at `date` :
nsvm_$backupdate.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
jseymour@LinxNet.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
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" <shwong@sebasasia.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.db
>
> backupdate=`date +%a_%Y`
> /bin/su - postgres -c "/usr/local/pgsql/bin/pg_dump -f
> /home/postgres/nsvm_$backupdate.db nsvm"
> echo "Backup at `date` :
> nsvm_$backupdate.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
"Siew Hui, Wong" <shwong@sebasasia.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
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.db
backupdate=`date +%a_%Y`
/usr/local/pgsql/bin/pg_dump -f /home/postgres/nsvm_$backupdate.db
excensio ## <--- the change
echo "Backup at `date` :
nsvm_$backupdate.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" <tgl@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" <shwong@sebasasia.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
>