Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
От | Amit Kapila |
---|---|
Тема | Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions |
Дата | |
Msg-id | CAA4eK1+X9ADua0b-t8+D8_YaPJXz3np9U9oh3UyLkYSJ=t0bOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions (Ian Barwick <ian.barwick@2ndquadrant.com>) |
Список | pgsql-hackers |
On Wed, Jun 19, 2019 at 10:09 AM Ian Barwick <ian.barwick@2ndquadrant.com> wrote: > > On 6/19/19 12:46 PM, Amit Kapila wrote: > > On Mon, Jun 17, 2019 at 8:20 PM Ian Barwick <ian.barwick@2ndquadrant.com> wrote: > >> On 6/15/19 1:08 AM, Stephen Frost wrote: > >> > * Amit Kapila (amit.kapila16@gmail.com) wrote: > >> >> Right. I think if possible, it should use existing infrastructure to > >> >> write to postgresql.auto.conf rather than inventing a new way to > >> >> change it. Apart from this issue, if we support multiple ways to edit > >> >> postgresql.auto.conf, we might end up with more problems like this in > >> >> the future where one system is not aware of the way file being edited > >> >> by another system. > >> > > >> > I agere that there should have been some effort put into making the way > >> > ALTER SYSTEM is modified be consistent between the backend and utilities > >> > like pg_basebackup (which would also help third party tools understand > >> > how a non-backend application should be modifying the file). > >> > >> Did you mean to say "the way postgresql.auto.conf is modified"? > >> > > > > Yes, that is what we are discussing here. I think what we can do here > > is to extract the functionality to set the parameter in .auto.conf > > from AlterSystemSetConfigFile and expose it via a function that takes > > (option_name, value) as a parameter. > > Yup, I was just considering what's involved there, will reply to another > mail in the thread on that. > > > Then we can expose it via some > > SQL function like set_auto_config (similar to what we have now for > > set_config/set_config_by_name). I think if we have something like > > that then pg_basebackup or any other utility can use it in a > > consistent way. > > Umm, but the point is here, the server will *not* be running at this point, > so calling an SQL function is out of the question. And if the server > is running, then you just execute "ALTER SYSTEM". > Sure, SQL function will be a by-product of this. Can't we expose some function that can be used by base backup? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: