Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
От | Tom Lane |
---|---|
Тема | Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
Дата | |
Msg-id | 32192.1375725400@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to
change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf
values to be changed via SQL [review])
Re: File-per-GUC WAS: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > I'll also point out that some of our settings only really "work" in > combinations of two or more settings. For example, one doesn't want to > set archive_mode = on unless one is setting archive_command as well. > And generally if one sets sequential_page_cost, one is changing the > other cost parameters as well. And logging parameters are generally > managed as a set. > So the case of two sessions both modifying ALTER SYSTEM SET, and one > succeeding for some-but-all-GUCS, and the other succeeding for > some-but-not-all-GUCs, would not be user-friendly or pretty, even if > each setting change succeeded or failed atomically. That is a killer point. So really the value of the global lock is to ensure serializability when transactions are updating multiple GUCs. regards, tom lane
В списке pgsql-hackers по дате отправления: