Re: TODO list

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
> Tom Lane said:
>> On an implementation level, where are you thinking of enforcing this?

> Without digging deeply at all I thought probably in the postmaster.

Nah, that's a nonstarter, because the postmaster has basically no
information about its children except for their PIDs and cancel keys.
In particular it does not know which database or user each one is for,
and really can't because the connection request packet is not input
from the client connection until after fork().

AFAICS there's really no other way to get this information than by
looking in shared memory. The PGPROC array already has info about
connected databases. I don't think it stores info about session user,
but that would be an easy and cheap addition.

> I'm not at all dogmatic about using pg_hba.conf - it just seemed similar
> to the info we carry there.

It's not necessarily a bad idea; we'd just need to adjust our theory
about when the cached pg_hba.conf data can be freed.

regards, tom lane

Tom Lane said:
> Andrew Dunstan <andrew(at)dunslane(dot)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

Tom Lane wrote:

>"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>
>
>>Tom Lane said:
>>
>>
>>>On an implementation level, where are you thinking of enforcing this?
>>>
>>>
>
>
>
>>Without digging deeply at all I thought probably in the postmaster.
>>
>>
>
>Nah, that's a nonstarter, because the postmaster has basically no
>information about its children except for their PIDs and cancel keys.
>In particular it does not know which database or user each one is for,
>and really can't because the connection request packet is not input
>from the client connection until after fork().
>
>AFAICS there's really no other way to get this information than by
>looking in shared memory. The PGPROC array already has info about
>connected databases. I don't think it stores info about session user,
>but that would be an easy and cheap addition.
>
>
>
>>I'm not at all dogmatic about using pg_hba.conf - it just seemed similar
>>to the info we carry there.
>>
>>
>
>It's not necessarily a bad idea; we'd just need to adjust our theory
>about when the cached pg_hba.conf data can be freed.
>
>
>

Did we reach a concensus about how this should be done? From a config
file? If so, should it be pg_hba.conf? Or from a table?

cheers

andrew