[ADMIN] su: /bin/bsh Permission denied
The error message is
"su: /bin/bash Permission denied". The following is my startup script.
It is okay when it is run on command line.
It fails when it is called in /etc/init.d as Linux boots.
What do I need to do?
Thanks
#! /bin/sh
# PostgreSQL startup/shutdown script
#
#
case "$1" in
start)
pid=`pgrep postmaster`
if [ -n "$pid" ]
then
echo "PostgreSQL is already running\n"
else
rm -f /tmp/.s.PGSQL.* > /dev/null
echo "Starting PostgreSQL ..."
su - postgres -c '/usr/local/pgsql/bin/pg_ctl start -D
/usr/local/pgsql/data -s -l /usr/local/pgsql/data/pg.log'
sleep 1
pid=`pgrep postmaster`
if [ -n "$pid" ]
then
echo "PostgreSQL is running"
else
echo "PostgreSQL failed to start"
fi
fi
;;
stop)
echo "Stopping PostgreSQL ..."
su - postgres -c '/usr/local/pgsql/bin/pg_ctl stop -D /usr/local/pgsql/data'
sleep 2
pid=`pgrep postmaster`
if [ -n "$pid" ]
then
echo "PostgreSQL failed to stop"
else
echo "PostgreSQL is stopped"
fi
;;
status)
status postmaster
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: postgresql {start|stop|status|restart}"
exit 1
esac
exit 0
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[ADMIN]
approve vYyvLS unsubscribe pgsql-admin [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] caching table/query
Tsirkin Evgeny wrote: Well i guess that there are cases where that is not so.However i understand that postgres does not have any way accept the automatic. Largely true. There may be ways of forcing a from-memory query once the system is in place, but I am not sure that this is always what you want, it would not be pretty, and might have some real performance issues. My suggestion is that you wait until your system is in operation and then look first for general tuning help before you even consider trying to impliment a memory-cached table in your application. Just for the record, I can think of at least one way of hacking this on, but it seems like it should be an absolutely last resort rather than a first impulse. PostgreSQL can do this, but you probably don't want it to. Best Wishes, Chris Travers begin:vcard fn:Chris Travers n:Travers;Chris email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [ADMIN] pg_restore hangs on 'some' HP-UX machines
Hi Chris, > So basically it is hanging when writing to the socket. Does > this change if you use TCP/IP (say adding a -h localhost to > your commandline)? This seems to work on one of my test machines where pg_restore was failing before...still need to make sure that this will work always, but is definitely a promising start. Thanks a bunch! Gopal. > -Original Message- > From: Chris Travers [mailto:[EMAIL PROTECTED] > Sent: Saturday, July 16, 2005 3:35 AM > To: Gopal Srinivasa; pgsql-admin@postgresql.org > Subject: Re: [ADMIN] pg_restore hangs on 'some' HP-UX machines > > I don't have any experience on HP-UX so take this with a > grain of salt... > > > > Gopal Srinivasa wrote: > > >The 'funny' thing is that it works perfectly on some HP-UX > systems and > >hangs on some others. I've seen it happen on both IA and PA > >architectures. Also, sometimes deleting some strings and restoring > >works, but the process is not repeatable. > > > > > > > I am assuming you are using ECC RAM, and that the hardware is > good. If there is any doubt here, you may want to look into > diagnostics on these areas. > > Just checking obvious things: Same version of libc on both > working and nonworking systems? Any updates that you know of > on working computers > that are not on nonworking systems? What about the kernel > (for socket > handling)? Any difference there? > > >I attached gdb to the pg_restore process and here is the > output of "bt": > > > >(gdb) attach 9249 > >Attaching to program: > /opt/iexpress/postgresql/bin/pg_restore, process > >9249 0x6000c058d890:0 in _poll_sys+0x30 () from > >/usr/lib/hpux32/libc.so.1 > >(gdb) bt > >#0 0x6000c058d890:0 in _poll_sys+0x30 () from > >/usr/lib/hpux32/libc.so.1 > >#1 0x6000c05a2860:0 in poll+0x120 () from > >/usr/lib/hpux32/libc.so.1 > >#2 0x6000c189ee90:0 in pqSocketPoll+0x120 () > > from /usr/lib/hpux32/libpq.so.3 > > > > > > So basically it is hanging when writing to the socket. Does > this change if you use TCP/IP (say adding a -h localhost to > your commandline)? > > In combination with the error about incomming connections, I > wonder if something is up with the socket handling on the > affected systems... > > Best Wishes, > Chris Travers > Metatron Technology Consulting > > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [ADMIN] functions vs stored procedures
Alvaro Herrera wrote: Wow, incredible. You misread the whole documentation. I certainly did, I read it with more care this time. It is a great solution when we're required to return a single record with a custom type, which are few but there certainly are. I wonder if you know any tricks to do something similar but returning rowsets instead of a single record? I'm currently doing some tests with cursor references, which I've been sugested on another thread. Thanks for your help, and sorry for not paying the appropriate attention to your previous hint ;) Regards, Ezequiel Tolnay ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[ADMIN] help! I can not start postgreSQL service!
Hi everyone, I got a problem. When I try to start postgreSQl service in Windows, I can not start it. The error message is "Could not start the postgreSQL service on Local Computer. The service did not return an error. This could be an interal Windows error or an internal service error". I appreciate any advice or suggestions! Thank you very much! Jiang __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[ADMIN] Corrupt table, is zero_damaged_pages available in v7.2?
We have "one" corrupted table in a v7.2.4 database. The others are good. We have identified the table should have 25 rows in it, and using pg_dump we can get the first 10. I was wondering if we could use the zero_damaged_pages under v7.2 to hopefully skip over the corrupted data and read the remaining records. Is this parameter only available in v7.3+? I am in the process of getting a source build tree together to build pg_filedump hopefully. Thanks - Eric ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
