Thread: pgsql/src/backend/utils/adt (ri_triggers.c)
Date: Monday, September 25, 2000 @ 18:34:20
Author: petere
Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/adt
from hub.org:/home/projects/pgsql/tmp/cvs-serv45883/src/backend/utils/adt
Modified Files:
ri_triggers.c
----------------------------- Log Message -----------------------------
When the RI triggers lock the PK table, temporarily switch the current user
id to the owner of the PK table, to avoid permission problems.
Peter Eisentraut - PostgreSQL wrote: > > Date: Monday, September 25, 2000 @ 18:34:20 > Author: petere > > Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/adt > from hub.org:/home/projects/pgsql/tmp/cvs-serv45883/src/backend/utils/adt > > Modified Files: > ri_triggers.c > > ----------------------------- Log Message ----------------------------- > > When the RI triggers lock the PK table, temporarily switch the current user > id to the owner of the PK table, to avoid permission problems. Are there any changes for Stephan's question ? Stephan Szabo wrote: > > As a question, since I don't have a source tree available here at work, > will there be an issue if an elog occurs between the various two user id > sets? Just wondering, because most of those statements are do some > SPI thing or elog. Regards. Hiroshi Inoue
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
>> When the RI triggers lock the PK table, temporarily switch the current user
>> id to the owner of the PK table, to avoid permission problems.
> Are there any changes for Stephan's question ?
> Stephan Szabo wrote:
>> As a question, since I don't have a source tree available here at work,
>> will there be an issue if an elog occurs between the various two user id
>> sets? Just wondering, because most of those statements are do some
>> SPI thing or elog.
It'll certainly be necessary for xact abort to restore the original
user ID setting. Peter, did you do that already?
regards, tom lane
Re: pgsql/src/backend/utils/adt (ri_triggers.c)
From
520083510237-0001@t-online.de (Peter Eisentraut)
Date:
Tom Lane writes: > It'll certainly be necessary for xact abort to restore the original > user ID setting. Peter, did you do that already? That's done by the setjmp/longjmp, no? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
520083510237-0001@t-online.de (Peter Eisentraut) writes:
> Tom Lane writes:
>> It'll certainly be necessary for xact abort to restore the original
>> user ID setting. Peter, did you do that already?
> That's done by the setjmp/longjmp, no?
Not automatically, surely. If there is an alterable global variable
containing the effective UID, then you must take care to reset it to
the session value during transaction abort --- ie, somewhere in the
transaction abort processing invoked by AbortTransaction in
backend/access/transam/xact.c. (The same goes for any other
status variable that might be temporarily altered by a transaction,
of course. This is one reason why transient changes in globals are
A Bad Thing to be studiously avoided whenever possible. But sometimes
you gotta have 'em.)
regards, tom lane
Tom Lane writes: > > Tom Lane writes: > >> It'll certainly be necessary for xact abort to restore the original > >> user ID setting. Peter, did you do that already? > > > That's done by the setjmp/longjmp, no? > > Not automatically, surely. Duh, of couse not. What was I smoking when I read the libc manual? The odd thing is that I did test for this and I could not get a failure (i.e., current_user != session_user after elog due to RI violation). Anyway, the fix is on the way. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Hiroshi Inoue writes: > > When the RI triggers lock the PK table, temporarily switch the current user > > id to the owner of the PK table, to avoid permission problems. > > Are there any changes for Stephan's question ? I did respond to his concern but probably hub.org's mail filters ate it (idiot ISP rewriting mail headers). That would explain why no one stopped me then. Sorry. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/