Thread: Logging - pg_options format change?
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.
What I'm proposing is to wrap the existing stuff in a backwards-compatible manner,
but extend it. Like so:
---------------------------------------------------
# postgresql options
debugging {fooparam+barswitchdumplevel = 11
}
logging {# details to follow
}
---------------------------------------------------
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?
Thanks,
Tim Holloway
Tim Holloway <mtsinc@southeast.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
> Tim Holloway <mtsinc@southeast.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. With a 7.0 release, I think we can revamp that file without too many complaints. pg_options file is fairly new, and it is an administrator's thing, and only has to be done once. Seems like a revamp to make it clear for all users would help. Having two files would mean explaining that to people for ever. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > > > Tim Holloway <mtsinc@southeast.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. > > With a 7.0 release, I think we can revamp that file without too many > complaints. pg_options file is fairly new, and it is an administrator's > thing, and only has to be done once. Seems like a revamp to make it > clear for all users would help. Having two files would mean explaining > that to people for ever. > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 Not to worry - the operative word was "wrap". In fact, I planned to leave the existing debug parser intact and just jump into it if the proper trigger for extended syntax isn't seen (also as a subprocessor if it IS seen). I've been on the receiving end of trauma too many times myself. I had considered making a "postgresql.conf" file with an option for debugging statements, but the net effect would just be the same anyway. Besides, Apache went the multi-config file route and regretted it. I'd rather not repeat history if a little advance planning can avoid it. There's another consideration. If a SIGHUP rescanned the ENTIRE configuration and there were two config files, BOTH of them would end up being processed anyway. Tim Holloway
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