Re: Thread-safe getopt()

On 19.05.25 22:22, Heikki Linnakangas wrote:
>> - getopt()
>>
>> This needs a custom replacement.  (There is no getopt_r() because
>> programs usually don't call getopt() after startup.)
>>
>> (Note: This is also called during session startup, not only during
>> initial postmaster start.  So we definitely need something here, if we
>> want to, like, start more than one session concurrently.)
>
> Here's a patch for a thread-safe version of getopt(). I implemented it
> as two functions, pg_getopt_start() and pg_getopt_next(). Since there's
> no standard to follow, we have freedom on how to implement it, and IMHO
> that feels more natural than the single getopt() function. I took the
> implementation from the getopt() replacement we already had for
> platforms that don't have getopt(), moving all the global variables it
> used to a struct.
>
> The last patch attached replaces all calls in the server to use the new
> variant, but leaves all the calls in client programs alone. I considered
> changing the client programs as well, but there's no immediate need, and
> it seems nice to use OS functions when possible.
>
> (The first patch fixes a little harmless bug in get_stats_option_name()
> that's gone unnoticed since 2006 but got in the way now.)

That first patch seems like a genuine latent bug that should be fixed.

The API you have created here looks pretty good to me.

I don't think we need to apply this to BootstrapModeMain() or
PostmasterMain(), it would be sufficient to use it in
process_postgres_switches() in tcop/postgres.c. It don't see any
advantage in using it where not needed (let alone client programs).

(I don't suppose there is a way to get rid of the need to do
command-line option parsing for the startup packet. It seems to be too
widely used.)