Re: Question: drop database problem - Mailing list pgsql-admin

From Tom Lane
Subject Re: Question: drop database problem
Date
Msg-id 3852.1098760419@sss.pgh.pa.us
Whole thread Raw
In response to Re: Question: drop database problem  (Ben Kim <bkim@coe.tamu.edu>)
Responses Re: Question: drop database problem
List pgsql-admin
Ben Kim <bkim@coe.tamu.edu> writes:
> I'm starting it with something like the following, as root in /etc/init.d
> script.

> su pgsql -c "/usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data
>             -p /usr/local/pgsql/bin/postmaster start"

> And pgsql has PGDATA3 defined in .cshrc.

su is most likely executing its -c command with /bin/sh, which will pay
zero attention to .cshrc.  You may need to set up a .profile as well as
.cshrc.  Also, I think that su won't cause *any* of these setup scripts
to be executed unless you use the "-" or "-l" options; a bare su just
runs the command in your current root environment.

This stuff varies across different Unix variants, but it's uniformly
a source of gotchas :-(.  Read your su and shell man pages carefully.

> Will I have to shut down the server and restart it (introduce PGDATA3
> properly) before I can drop that particular database?

Yeah.  That part's not so hard: if you restart the postmaster manually
then it will inherit your interactive variables.  But I do *not*
recommend that, because it'll break after your next reboot.  You need to
do the legwork to be sure that the variables show up in the basic
boot-time context.

Again, this definitely sucks, and we are moving away from it as fast as
we can.  But that's where things stand in current releases.

            regards, tom lane

pgsql-admin by date:

Previous
From: "Nikhil Parva"
Date:
Subject: unregister
Next
From: Rajesh Kumar Mallah
Date:
Subject: Limiting postmaster to listen in a particular ip address only