Re: TODO list - Mailing list pgsql-hackers

From Þórhallur Hálfdánarson
Subject Re: TODO list
Date
Msg-id 20031217230348.B13132@tol.li
Whole thread Raw
In response to Re: TODO list  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TODO list  ("Andrew Dunstan" <andrew@dunslane.net>)
List pgsql-hackers
-*- Tom Lane <tgl@sss.pgh.pa.us> [ 2003-12-17 22:46 ]:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > case 6 - limit all users' connections regardless of database:
> > limit all all n
> 
> That's called max_connections.  Don't think we need a redundant
> implementation of same ...
> 
> Another little nitpick is that I don't like assuming that "any" and
> "all" are never going to be used as database or user names.  (I know
> that pg_hba.conf already uses "all" this way, and IMHO that was a bogus
> decision.  Something like "*" would have been less likely to collide.)
> 
> On an implementation level, where are you thinking of enforcing this?
> pg_hba.conf would not be very appropriate for the most likely place to
> put it, which is in backend startup shortly after establishing a PGPROC
> entry (with the data about numbers of active connections obtained by
> scanning the PGPROC array for other backends connected to the same
> database or with the same userid).  I think we've thrown away the
> PostmasterContext long before that, so we couldn't use cached
> pg_hba.conf data without some redesign of the startup sequence.

I'd like to mention that administrators likely to use the this feature would probably like to be able to tune this
withouthaving to modify a file -- updating via SQL (=> storing this in a system table) would be extremely nice...
 

-- 
Regards,
Tolli
tolli@tol.li


pgsql-hackers by date:

Previous
From: "Robert Bedell"
Date:
Subject: Re: OLAP CUBE/ROLLUP Operators and GROUP BY grouping sets
Next
From: David Felstead
Date:
Subject: Re: TODO list