Обсуждение: 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

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/