Re: profiling connection overhead - Mailing list pgsql-hackers

From Robert Haas
Subject Re: profiling connection overhead
Date
Msg-id AANLkTi=b6dPiLTSpdvqVRDx0ZTUOob7BCNuAc4y2wXoB@mail.gmail.com
Whole thread Raw
In response to Re: profiling connection overhead  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On Mon, Dec 6, 2010 at 9:37 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Robert Haas's message of lun dic 06 23:09:56 -0300 2010:
>> On Mon, Dec 6, 2010 at 2:47 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> >
>> >> Please explain more precisely what is wrong with SET SESSION
>> >> AUTHORIZATION / SET ROLE.
>> >
>> > 1) Session GUCS do not change with a SET ROLE (this is a TODO I haven't
>> > had any time to work on)
>> >
>> > 2) Users can always issue their own SET ROLE and then "hack into" other
>> > users' data.
>>
>> Makes sense.  It would be nice to fix those issues, independent of
>> anything else.
>
> It seems plausible to fix the first one, but how would you fix the
> second one?  You either allow SET ROLE (which you need, to support the
> pooler changing authorization), or you don't.  There doesn't seem to be
> a usable middleground.

You could add a protocol message that does a "permanent" role switch
in a way that can't be undone except by another such protocol message.Then connection poolers could simply refuse to
proxythat particular 
message.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: wal_sender_delay is still required?
Next
From: Alvaro Herrera
Date:
Subject: Re: wal_sender_delay is still required?