Re: SQL access to database attributes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SQL access to database attributes
Date: 2014-05-24 19:29:49
Message-ID: 7942.1400959789@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <jim(at)nasby(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2014-05-24 22:50:41 Re: buildfarm / handling (undefined) locales
Previous Message Tom Lane 2014-05-24 19:19:11 Re: Issue with GRANT/COMMENT ON FUNCTION with default