This project is archived and is in readonly mode.
patch: postgresql socket detection and help
The patch: generates normal database.yml with a small additonal note about pgsql domain sockets, unless a socket is detected in /tmp or /var/run/postgresql. In that case, working host and port params are set to make this work out of the box.
Good news is this could also save the user from configuring authentication in pgsql, since by default ident is used for domain sockets.
Remaining problems:
- I have no ideas for how to write a simple test for this that wouldn't be messy - but I don't feel good about not having tests for this
- The problem is actually on the distro - maintainer's side (libpq-dev) and may be specific to a distro/version (e.g.libpqdev=psql=8.3.6-0ubuntu8.10)
- Only two folders are checked - I have no informatin about other possible distro/path combinations ( like the long mysql socked path list)
- It would be nice to detect pgsql domain socket connection problems and give a hint to the user along with the standard socket error - but I cannot think of a clean way to do this using pg.
- I tested this only with pg
There is a hairy problem with postgresql domain socket support that boils down to:
- people are having socket connection errors with posgresql and have no clue other than using tcp with localhost
- the socket paths are compiled into bo the server and client (libpq), and there isn't and won't be a API for getting this path (other than strace ;) )
- the socket path can be passed through the host parameter, which nobody on the internet seems to know about (mysql OTOH actually has a working :socket option)
- none of my stock Ubuntu setups ever worked AFAIR - the server and client used different socket paths. I have no idea how this is possible, since a since #define is used for both packages - I'll file a bug in Launchpad as soon as I test the latest versions of postgres and libpq-dev.
- a workaround is to configure the server to use the same path as the client (libpq) - which is what I did until I dug through libpq code and found the host workaround.
-
postgresql_socket_detection.diff
3.47 KB
-
Cezary BaginskiProbable cause: long ago one version of postgres created the system config file upon installation with the socket dir set to /tmp. At one point, the system default changed to /var/run/postgres/. But the config file was never updated, which never stopped the server or psql client from working with the socket in /tmp.
But... libpq doesn't read the config file, so it failed trying to connect to the compiled-in default, /var/run/postgres.
So, anyone who has a fresh Ubuntu installation without /tmp in the config, should have everything working out of the box.
-
-
Santiago Pastorino- State changed from new to open
- Tag changed from database.yml, generators, libpq, patch, postgresql, railties to databaseyml, generators, libpq, patch, postgresql, railties
- Importance changed from to
This issue has been automatically marked as stale because it has not been commented on for at least three months.
The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.
Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.
-
Santiago Pastorino
- State changed from open to stale