2017-01-04 17:58 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > > See attached scripts for instance. >>> >> >> Your test shows so SET SESSION has not transactional behaviour - the >> transactions fails, but the value is not reverted to NULL. >> > > There are *two* function calls, the first fails and the second succeeds. > Here is the trace with a some comments: > > [...] > > ## SET SESSION x.x = 'null'; > SET > -- previous has set x.x = 'null' > > ## SELECT setupSecurityContext(3); > -- first setup... function call > NOTICE: SET secured = FALSE > NOTICE: SET secured = TRUE > -- there is a SET to 'ok' just after this print > -- at the end the transaction fails: > ERROR: insert or update on table "log" violates foreign key constraint > "log_sid_fkey" > DETAIL: Key (sid)=(3) is not present in table "stuff". > -- no result is displayed from the SELECT > > ## SHOW x.x; > nul > -- the value is the initial value, it has been reverted > > ## SELECT setupSecurityContext(2); > -- second setup... function call > NOTICE: SET secured = FALSE > NOTICE: SET secured = TRUE > -- trues is displayed, the function succeeded > t > > ## SHOW x.x; > ok > -- the new value is shown
ok understand The logic depends on transactions and on nesting level (nesting doesn't depends on transactions only) /* * Do GUC processing at transaction or subtransaction commit or abort, or * when exiting a function that has proconfig settings, or when undoing a * transient assignment to some GUC variables. (The name is thus a bit of * a misnomer; perhaps it should be ExitGUCNestLevel or some such.) * During abort, we discard all GUC settings that were applied at nesting * levels >= nestLevel. nestLevel == 1 corresponds to the main transaction. */ void AtEOXact_GUC(bool isCommit, int nestLevel) Probably we should to use CallXactCallbacks instead - then is not a performance impact when there are not transactional variables. Regards Pavel > > > -- > Fabien. >
