On Thu, 21 Oct 2010, Tom Lane wrote:
Actually, I was saying that the script should *not* concern itself with the pidfile at all.
Tom, I understood what you wrote.
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?
No. It's been commented out forever, so it should be the default.
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.
The currently installed 8.3.3 has been running for some time now. I've not made any changes since last Friday (the last day I used one of the databases), and the system board failed Sunday afternoon, just after an OS upgrade.
Maybe your libpq came from someplace different than the postmaster executable?
I've no idea how that could have happened. Since I cannot start the postmaster I cannot run pg_dumpall. What's the pragmatic way for me to once again get postgres running (and, presumably, able to cleanly stop and restart when necessary)? Many thanks, Rich -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
