Re: [HACKERS] Logging - pg_options format change?
От | Tim Holloway |
---|---|
Тема | Re: [HACKERS] Logging - pg_options format change? |
Дата | |
Msg-id | 381635B9.6DEFE78A@southeast.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Logging - pg_options format change? (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: