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])

On 2013-08-05 13:56:40 -0400, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)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.

I don't think a global lock helps very much WRT this. Likely the lock
will be released after a single SET finishes, in that case it doesn't
guarantee much for a set of SETs. Even if we were to make it be released
only at session end, the session that wants to set something conflicting
will only be blocked by wanting to set the lock, it won't be prevented
from doing so. The SET will then succeed after the other session finished.

I don't think we're designing a feature that's supposed to be used under
heavy concurrency here. If you have users/tools doing conflicting
actions as superusers you need to solve that by social means, not by
technical ones.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services