Re: [HACKERS] Logging - pg_options format change?

From: Tim Holloway <mtsinc(at)southeast(dot)net>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Logging - pg_options format change?
Date: 1999-10-26 23:14:01
Message-ID: 381635B9.6DEFE78A@southeast.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
>
> > Tim Holloway <mtsinc(at)southeast(dot)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(at)candle(dot)pha(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tim Holloway 1999-10-26 23:33:44 Re: [HACKERS] Logging - pg_options format change?
Previous Message Bruce Momjian 1999-10-26 17:38:12 Re: [HACKERS] Current source from CVS won't compile.