I have traced down the postmaster-option-processing failure that Thomas
reported this morning. It appears to be specific to systems running
glibc: the problem is that resetting optind to 1 is not enough to
put glibc's getopt() subroutine into a good state to process a fresh
set of options. (Internally it has a "nextchar" pointer that is still
pointing at the old argv list, and only if the pointer points to a null
character will it wake up enough to reexamine the argv pointer you give
it.) The reason we see this now, and didn't see it before, is that
I rearranged startup to set the ps process title as soon as possible
after forking a subprocess --- and at least on Linux machines, that
"nextchar" pointer is pointing into the argv array that's overwritten
by init_ps_display.
While I could revert that change, I don't want to. The idea was to be
sure that a postmaster child running its authentication cycle could be
identified, and I still think that's an important feature. So I want to
find a way to make it work.
Looking at the source code of glibc's getopt, it seems there are two
ways to force a reset:
* set __getopt_initialized to 0. I thought this was an ideal solution
since configure could check for the presence of __getopt_initialized.
Unfortunately it seems that glibc is built in such a way that that
symbol isn't exported :-(, even though it looks global in the source.
* set optind to 0, instead of the more usual 1. This will work, but
it requires us to know that we're dealing with glibc getopt and not
anyone else's getopt.
I have thought of two ways to detect glibc getopt: one is to assume that
if getopt_long() is available, we should set optind=0. The other is to
try a runtime test in configure and see if it works to set optind=0.
Runtime configure tests aren't very appealing, but I don't much care
for equating HAVE_GETOPT_LONG to how we should reset optind, either.
Opinions anyone? Better ideas?
regards, tom lane
