From: | Tim Holloway <mtsinc(at)southeast(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Logging - pg_options format change? |
Date: | 1999-10-26 23:33:44 |
Message-ID: | 38163A58.2F9AFCA7@southeast.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 1999-10-27 00:52:55 | RE: System indexes are never unique indexes( was RE: [HACKERS] mdnblocksis |
Previous Message | Tim Holloway | 1999-10-26 23:14:01 | Re: [HACKERS] Logging - pg_options format change? |