This fixes the issue by omitting
postgresql.conf if a
listen_address is specified.
If the user specifies both,
listen_address takes precedence. This has been documented in
My rationale here is simply that adding a
listen_address requires two attribute changes, while changing
unix_socket_directory only requires one. If someone is intent on changing the unix socket, they'll probably leave
listen_address alone. On the other hand, if someone wants to listen on localhost, they might not know to set the socket value to nil as well. Therefore, I think this behavior is more likely to help out the user trying to listen on IP than confound the user trying to modify the socket.
I have also added tests which validate this behavior. I wasn't exactly sure where to place the "correctly sets unix_socket_directory" test, since one could argue that it belongs in either the 'with default settings' or the 'version specific settings' contexts. I put it in the latter, since that's where it lives in the 9.6 block. Let me know if it should go someplace else. I also moved the socket test inside the
renders postgresql.conf context in the 9.6 block in order to mirror the 9.2 block. There's a bit of repeated code here, so I'm thinking it might be possible to optimize readability a bit.
Now fixed by ensuring that a
pg_hba.conf entry is present for the specified
listen_address. Doing so allows for binding to both a Unix and TCP socket at once.
listen_address will use the first comma-separated address. (It's comma-separated as opposed to an array in order to maintain backwards compatibility, in case someone had worked around this issue before by using
md5_auth_cidr_addresses — but
listen_address could easily be changed to an array if desired.)