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+
	barswitch
	dumplevel = 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

Mon, 25 Oct 1999 20:01:15 -0400
Tim Holloway <mtsinc@southeast.net>
Logging - pg_options format change?
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

Tue, 26 Oct 1999 02:16:12 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Logging - pg_options format change? 
> 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

Tue, 26 Oct 1999 12:24:13 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Logging - pg_options format change?


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

Tue, 26 Oct 1999 19:14:01 -0400
Tim Holloway <mtsinc@southeast.net>
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

Tue, 26 Oct 1999 19:33:44 -0400
Tim Holloway <mtsinc@southeast.net>
Re: [HACKERS] Logging - pg_options format change?