Re: SQL access to database attributes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL access to database attributes
Date
Msg-id 7942.1400959789@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL access to database attributes  (Jim Nasby <jim@nasby.net>)
Responses Re: SQL access to database attributes  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Jim Nasby <jim@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$$
LIMIT1 FOR UPDATE;
 

> If you don't get a record back from that you abort; meanwhile no one else can disallow connections on that database
untilyou 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Issue with GRANT/COMMENT ON FUNCTION with default
Next
From: Tomas Vondra
Date:
Subject: Re: buildfarm / handling (undefined) locales