Thread

1. Re: [HACKERS] Logging - pg_options format change?

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-10-26T06:16:12Z

   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
   
   

2. Re: [HACKERS] Logging - pg_options format change?

   Bruce Momjian <maillist@candle.pha.pa.us> — 1999-10-26T16:24:13Z

   > 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
   
   

3. Re: [HACKERS] Logging - pg_options format change?

   Tim Holloway <mtsinc@southeast.net> — 1999-10-26T23:14:01Z

   
   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
   
   

4. Re: [HACKERS] Logging - pg_options format change?

   Tim Holloway <mtsinc@southeast.net> — 1999-10-26T23:33:44Z

   
   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