Tom Lane said:
> 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 ...
>
no - this was intended to limit *each* user - max-connections limits
total connections. Maybe I expressed it badly. (reinforces my point about
needing to make sure we get the semantics straight first).
> 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.)
>
I entirely agree. Let's change it. For a new major release people will
have probably need to do an initdb anyway.
> 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.
>
Without digging deeply at all I thought probably in the postmaster. But I
would defer to your good advice ;-)
I'm not at all dogmatic about using pg_hba.conf - it just seemed similar
to the info we carry there.
cheers
andrew