On 2020-11-09 07:08, Michael Paquier wrote:
As abstract namespaces don't have permissions, anyone knowing the name of the path, which should be unique, can have an access to the server. Do you think that the documentation should warn the user about that? This feature is about easing the management part of the socket paths while throwing away the security aspect of it.
We could modify the documentation further. But note that the traditional way of putting the socket into /tmp has the same properties, so this shouldn't be a huge shock.
When attempting to start a server that listens to the same port and uses the same abstract path, the second server started still shows a hint referring to a file that does not exist: LOG: could not bind Unix address "@tmp/.s.PGSQL.5432": Address already in use HINT: Is another postmaster already running on port 5432? If not, remove socket file "@tmp/.s.PGSQL.5432" and retry. Instead of showing paths with at signs, wouldn't it be better to mention it is an abstract socket address?
The @ is the standard way of representing this in the user interface and the configuration, so it seems sensible to me that way.
I am not sure that 0002 is an improvement. It would be more readable to move the part choosing what hint is adapted into a first block that selects the hint string rather than have the whole thing in a single elog() call.
Can you sketch how you would structure this? I realize it's not very elegant, but I couldn't come up with a better way that didn't involve having to duplicate some of the error messages into multiple branches.
-- Peter Eisentraut 2ndQuadrant, an EDB company https://www.2ndquadrant.com/
