Re: [HACKERS] Logging - pg_options format change?

Tim Holloway <mtsinc(at)southeast(dot)net> writes:
> Would it be objectionable if I altered the format of the pg_options
> file slightly? I feel the need to handle a somewhat more complex
> syntax for the logging subsystem.

While I'm not particularly wedded to the pg_options format, I wonder
whether it wouldn't be a better idea to create a separate file for
the logging control data. If I'm reading your proposal correctly,
the backend would no longer parse existing pg_options files --- and
that's certain to make dbadmins unhappy, even if the fix is easy.
Upgrades are always stressful enough, even without added complications
like forced changes to config files.

You could probably tweak the syntax so that an existing pg_options
file is still valid, but that might be a bit too klugy. What's
wrong with having two separate files? We can assume that this isn't
a performance-critical path, I think.

> Also, is YACC sufficently thread-safe that if a SIGHUP starts
> parsing options it won't collide with another task's in-progress
> parsing of, say a SELECT statement?

Don't even think of going there. Even if yacc/bison code itself can be
made reentrant (which I doubt; it's full of static variables) you'd also
have to assume that large chunks of libc are reentrant --- malloc() and
stdio in particular --- and I know for a fact that you *cannot* assume
that. There might be some platforms where it will work, but many others
won't.

Basically, the only thing that's really safe for a signal handler to do
is set an int flag to TRUE for a test in the main control paths to
notice at some later (hopefully not too much later) time. The
QueryCancel flag in the existing Postgres code is an example.

For the purposes of logging, I see no reason why it wouldn't be
good enough to reread the config file at the start of the next
query-execution cycle. There's no need to take the risks of doing
anything unportable.

regards, tom lane