On 6 March 2012 17:00, Adrian Klaver <adrian.klaver@gmail.com> wrote:
> On Tuesday, March 06, 2012 8:44:10 am Thom Brown wrote:
>
>> >> And if I start my development copy, this is the content of its
>> >> postmaster.pid:
>> >>
>> >> 27061
>> >> /home/thom/Development/data
>> >> 1331050950
>> >> 5488
>> >> /tmp
>> >> localhost
>> >> 5488001 191365126
>> >
>> > So how are getting the file above? I thought initdb refused to init the
>> > directory and that you could not find pid file it was referring to? Just
>> > on a hunch, what is in /tmp?
>>
>> I got the above output when I created a new data directory and initdb'd it.
>
> Still not understanding. In your original post you said
> /home/thom/Development/data was the original directory you could not initdb. How
> could it also be the new directory you can initdb as indicated by the
> postmaster.pid?
/home/thom/Development/data was causing problems so:
mv data databroken
mkdir data
initdb
... working fine again. I then used the postmaster.pid from this when
started up. But if I do:
pg_ctl stop
rm -rf data
mv databroken data
initdb
... error messages appear again.
> From your previous post:
> thom@swift:~/Development$ pg_ctl stop
> pg_ctl: could not send stop signal (PID: 2807): No such process
>
> Doing the above without qualifying which version of pg_ctl you are using or what
> data directory you are pointing is dangerous. The combination of implied
> pathing and preset env variables could lead to all sorts of mischief.
Unlikely since pg_ctl isn't available in my search path once I remove
my local development bin dir from it. All non-client tools for the
packaged version aren't available to normal users. Those are all in
/usr/lib/postgresql/9.1/bin. The only ones exposed to the search path
through symbolic links are:
clusterdb
createdb
createlang
createuser
dropdb
droplang
dropuser
pg_dump
pg_dumpall
pg_restore
psql
reindexdb
vacuumdb
vacuumlo
--
Thom
