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
