Re: SQL access to database attributes
От | Tom Lane |
---|---|
Тема | Re: SQL access to database attributes |
Дата | |
Msg-id | 7942.1400959789@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SQL access to database attributes (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: SQL access to database attributes
|
Список | 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 по дате отправления: