Re: [v9.2] Add GUC sepgsql.client_label

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: robertmhaas(at)gmail(dot)com, yebhavinga(at)gmail(dot)com, kaigai(at)kaigai(dot)gr(dot)jp, pgsql-hackers(at)postgresql(dot)org, jbrindle(at)tresys(dot)com
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Date: 2012-02-04 17:54:38
Message-ID: 11796.1328378078@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane wrote:
>> More to the point, a GUC rollback transition *has to always
>> succeed*. Period.

> [ counterexample showing we should sometimes disallow "RESET" ]

This actually isn't what I was talking about: a RESET statement is a
commanded adoption of a new value that happens to be gotten off the
stack, and there's not a lot of logical difficulty in letting it fail.
What I was concerned about was the case where GUC is trying to
re-establish an old value during transaction rollback. For example,
assume we are superuser to start with, and we do

begin;
set role unprivileged_user;
...
rollback;

The rollback needs to transition the role setting back to superuser.
A check based purely on allowed transitions would disallow that, since
it's not visibly different from the unprivileged_user trying to make
himself superuser. You have to take the context of the state change
into account.

And yeah, I agree it's a bug that you can do what Kevin's example shows.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-02-04 18:06:38 Re: Memory usage during sorting
Previous Message Kevin Grittner 2012-02-04 17:14:45 Re: [v9.2] Add GUC sepgsql.client_label