Rich Shepard <rshepard@xxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
