Re: [HACKERS] Logging - pg_options format change?

Tom Lane wrote:
> 
> > 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

Darn. I thought newer YACC programs had gotten rid of that kind of mess. But then
I thought the same of the C libs, too. Oh well.
I trust that it IS safe to use do the config reread using YACC if I do it as a
"query-execution" task? 
  Thanks!     Tim Holloway