Description of problem: A configuration parameter that works in postgresql Version-Release number of selected component (if applicable): postgresql-9.1.5-1.fc17.x86_64 (does not work) postgresql-9.1.3-3.fc17.x86_64 (works) How reproducible: Reliably Steps to Reproduce: 1. Download the attached test script into breakpg.sh 2. Run ./breakpg.sh Actual results: Test script ends by printing "nay" Start-up of database fails. breakdb/log file has the following error message: FATAL: unrecognized configuration parameter "unix_socket_directory" Running pg_ctl status -D breakdb/data prints: pg_ctl: no server running Expected results: Test script ends by outputting "ok" Running pg_ctl status -D breakdb/data prints something like: pg_ctl: server is running (PID: 17527)
Created attachment 608422 [details] Test case script
Created attachment 608426 [details] Updated test case script The previous test case script contais a function that is not actually needed, as a leftover from modifying another script into a test case script. This new version is a bit simpler.
Not a bug. It's called unix_socket_directories now (and you can have more than one in the list). In any case, fooling with that value has never really been considered supported in Fedora/RHEL --- are you sure you need to change it?
Thank you for the quick response. I think it is a bit surprising for a configuration file syntax to change like this in what looks like a maintenance update to a stable Fedora release. Documentation in [1] also does not warn about the lack of support for the option. Worse, it also lists just the old syntax which is not accepted by the 9.1.5 version the document is titled to describe. However, maybe upstream would be a more appropriate place to whine about this. Thanks for pointing me to the right direction. The reason for overriding the socket directory is that I am setting up a throwaway postgresql instance against which to run some automated tests of a piece of software. This way a local developer can safely hack at stuff and run the tests at without having to be afraid of breaking a system-wide database. References: [1] http://www.postgresql.org/docs/9.1/static/runtime-config-connection.html
Well, upstream didn't change it --- rather, we chose to back-port a later upstream feature into the Fedora package in order to deal with bug #825448. The Fedora documentation for postgresql describes the new configuration variable, but of course the upstream 9.1 documentation would not.
BTW, forgot to mention this, but: usually the preferred way to set up an alternate postmaster is with a non-default port number (and don't forget the non-default data directory, of course). There's no need to use a different socket directory if you do it that way. It's usually relatively easy to get client code to use a different port number, but changing its idea of the socket directory can be hard to impossible. And of course, if you're using TCP-connection clients, changing the socket directory is irrelevant anyway. These considerations are why we felt we could get away with changing the Fedora package's socket-directory behavior in a minor release.
Thank you for the explanation. While it is easy to use the PGHOST environment variable to direct at least some postgresql clients (including the ones I work with) to a custom socket directory, I will consider using just a custom port number. However, in my current opinion, it does not look nearly as clean as having the developers run tests against a database instance that is entirely contained within the account of the developer, similarly to all the other machinery that is used for running the tests.