Re: Question: drop database problem

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Question: drop database problem
Дата
Msg-id 3852.1098760419@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Question: drop database problem  (Ben Kim <bkim@coe.tamu.edu>)
Ответы Re: Question: drop database problem  (Ben Kim <bkim@coe.tamu.edu>)
Список 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 по дате отправления:

Предыдущее
От: "Nikhil Parva"
Дата:
Сообщение: unregister
Следующее
От: Rajesh Kumar Mallah
Дата:
Сообщение: Limiting postmaster to listen in a particular ip address only