Re: TODO list

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: TODO list
Date: 2003-12-18 01:10:25
Message-ID: 15753.1071709825@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-12-18 01:20:03 Re: OLAP CUBE/ROLLUP Operators and GROUP BY grouping sets
Previous Message Jonathan Gardner 2003-12-18 00:48:33 Limiting per user and per db accesse (was TODO list)