Re: TODO list - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TODO list
Date
Msg-id 15753.1071709825@sss.pgh.pa.us
Whole thread Raw
In response to Re: TODO list  ("Andrew Dunstan" <andrew@dunslane.net>)
Responses Re: TODO list  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
"Andrew Dunstan" <andrew@dunslane.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


pgsql-hackers by date:

Previous
From: Jonathan Gardner
Date:
Subject: Limiting per user and per db accesse (was TODO list)
Next
From: Tom Lane
Date:
Subject: Re: OLAP CUBE/ROLLUP Operators and GROUP BY grouping sets