On Tue, Aug 6, 2013 at 10:54:22AM -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > 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.
>
> If this actually gets used by puppet or another CMS, the chances of the
> 'social means' being successful drop drastically.
>
> I agree that it doesn't need to work under heavy concurrency, but it
> should do something sensible if it happens- perhaps even just throwing
> an error if it can't acquire the lock immediately, warning the user that
> some other process is trying to modify the config concurrently.
My guess is that most users are going to do:
SHOW log_min_duration_statement;
SET log_min_duration_statement = 3;
i.e. there isn't going to be any way to _lock_ that value between
viewing it and setting it, and hence no way to warn users.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
