Rich Shepard <rshepard@appl-ecosys.com> writes:
> On Wed, 20 Oct 2010, Tom Lane wrote:
>> In particular, I wonder whether the script's refusal to start if the
>> pidfile already exists accounts for your report that it fails to
>> auto-restart after a reboot.
> This clears up my uncertainty. The pidfile should not exist after a clean
> shutdown, so it should be removed after a crash, too.
Actually, I was saying that the script should *not* concern itself with
the pidfile at all. Having a script that automatically removes the
pidfile is a big foot-gun: if you ever run it at any time other than
system boot, you'll destroy a critical interlock against starting two
postmasters in the same data directory. The postmaster is perfectly
capable of getting rid of a stale pidfile by itself, and is far less
likely to do the wrong thing than a scripted removal is.
> Yet, when I try to access one of my databases I cannot:
> [rshepard@salmo ~]$ psql aesi
> psql: could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
> There was no postgres running before I ran /etc/rc.d/rc.postgresql start.
> There is also no socket on /tmp.
Hmm, maybe the postmaster thinks it should be putting the socket file
someplace other than /tmp. Have you got a nondefault setting of
unix_socket_directory in postgresq.conf? Also, if you're using the
distro's build of postgresql not your own, it's possible that the
compiled-in default for unix_socket_directory isn't /tmp --- though
the copy of libpq you're using seems to think it is /tmp. Maybe your
libpq came from someplace different than the postmaster executable?
regards, tom lane