pgsql/src/backend/utils/adt (ri_triggers.c)

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

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/