Re: Glitch in handling of postmaster -o options
От | Marko Kreen |
---|---|
Тема | Re: Glitch in handling of postmaster -o options |
Дата | |
Msg-id | 20010930174020.A887@l-t.ee обсуждение исходный текст |
Ответ на | Re: Glitch in handling of postmaster -o options (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Glitch in handling of postmaster -o options
|
Список | pgsql-hackers |
On Sun, Sep 30, 2001 at 12:54:25AM +0200, Peter Eisentraut wrote: > Tom Lane writes: > > While that's not a fatal problem, I could imagine *much* more serious > > misbehavior from inconsistent settings of some GUC parameters. Since > > backends believe that these parameters have PGC_POSTMASTER priority, > > they'll accept changes that they probably oughtn't. For example, > > postmaster -o --shared_buffers=N > > will cause things to blow up very nicely indeed: backends will have > > a value of NBuffers that doesn't agree with what the postmaster has. > > This is a bug. PG 7.1 wouldn't let this thing go through but with all the > changes made for the RESET ALL functionality (I think) this has snuck in. > > My best guess is that this change was made to allow using > SetConfigOption() in PostgresMain() with options that are really > postmaster-global and are passed down to the backends. But AFAICS there > aren't any such options anymore. > > > I wonder whether we should retire -o. How about putting -o stuff after -p? That way only postmaster code can set PGC_POSTMASTER options for a backend, no way for user to mess up. ATM this would break -o -F tho'. -- marko
В списке pgsql-hackers по дате отправления: