Ouch! I've never needed that before. These files have always gone in /tmp. OK, so why is it different now we are putting them elsewhere? It turns out that the directory has been created by the RPM with permissions different from /tmp, and only the postgres user can write there.could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": Permission denied
My solution (which I hope our RPM maintainers adopt) was to change the permissions on the directory like this, making them the same as those of /tmp:
After that when I try to start the database everything is as expected.sudo chmod 1777 /var/run/postgresql
That would kind of defeat the purpose of moving it from /tmp in first place. The idea is exactly to make sure that only the postgres server account can create the socket and no race conditions are possible.
ReplyDeleteSo we protect the postgres user and throw everyone else under the bus? If there is a significant race condition problem with the fact that Postgres runs on multi-user system this doesn't look like a good solution to me.
ReplyDeleteThe postgresql package (note: not postgresql source) is designed by default to run as the postgres user. It isn't that users are being thrown under the bus, it is that the users are expected to do it a certain way, the right way. You are not a user, you are a hacker. Your requirements are different and you are obviously capable of handling the issue without sacrificing the quality of the experience for that who are not hackers.
ReplyDelete