Jim Nasby <j...@nasby.net> writes:
> On 5/24/14, 8:14 AM, Tom Lane wrote:
>> Perhaps it'd be wise to have a safety check to disallow turning off
>> datallowconn for the last connectable database? Although it couldn't be
>> bulletproof due to race conditions, so maybe that'd just be nannyism.
> BTW, I think the race condition could be eliminated if we did something like
> (forgive the user-space semantics):
> SELECT datallowconn FROM pg_database WHERE datallowconn AND datname <>
> $$database we're disallowing connections on$$ LIMIT 1 FOR UPDATE;
> If you don't get a record back from that you abort; meanwhile no one else can
> disallow connections on that database until you commit or rollback.
Meh. That would take out a rowlock on a database unrelated to the one
we're modifying, which would be (a) surprising and (b) subject to
deadlocks.
I don't really object to doing an unlocked check for another such
database, but I'm not convinced that additional locking to try to
prevent a race is worth its keep.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
