Tom Lane said: > Andrew Dunstan <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
