Re: Ability to listen on two unix sockets

Honza Horak <hhorak(at)redhat(dot)com> writes:
> Alternate-port-number support has been removed from the patch, as per
> Tom's e-mail from 07/03/12. It can be add in the future, if we really
> need it.

I've reviewed and committed this. There were some cosmetic things
I adjusted, as well as a couple of fairly large non-cosmetic things:

* I did not like rearranging the order in which TCP and Unix sockets
get opened. It's possible that this comment in postmaster.c

* For the same reason, it's best to grab the TCP socket(s) before the
* Unix socket.

is no longer relevant, but I'm doubtful of that. The reason you had
switched them appeared to be to update the SOCKET_DIR line in
postmaster.pid before updating the LISTEN_ADDR line, but the only reason
to do that is the implementation restriction in AddToDataDirLockFile
that it can't update a non-last line in the pidfile. That's not that
hard to get rid of, and it's something we'd probably want someday
anyway, so I fixed that function and put the socket opening order back
as it had been.

* The code in pqcomm.c queued another on_proc_exit function for each
socket. There was no purpose in that since the first one would do all
the work, but the postmaster's on_proc_exit array isn't very large,
and it's not hard to foresee the useless entries causing a failure by
overflowing the array. Similarly, miscinit.c queued an on_proc_exit
function for each lock file it had to get rid of, which was fine as
long as there was an upper bound of 2, but now not so much. I fixed
them to use similar logic of keeping a list of file names and queueing
the on_proc_exit function when adding the first list entry.

* You'd fixed TouchSocketFiles to touch all the sockets, but missed
making TouchSocketLockFiles touch all their lock files. That would
be problematic if /tmp was a non-first entry in the list.

I also simplified the GUC interactions by leaving the GUC variable as a
simple string and splitting it at the point of use, so that the code is
more parallel to what we do with listen_addresses.

regards, tom lane