Re: [HACKERS] proposal: session server side variables
От | Pavel Stehule |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables |
Дата | |
Msg-id | CAFj8pRB4E=jeFS1H-eL-ezVB2c8JOXV+wESBcAfYWy8MjUzUag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [HACKERS] proposal: session server side variables
|
Список | pgsql-hackers |
2017-01-04 17:58 GMT+01:00 Fabien COELHO <coelho@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.
В списке pgsql-hackers по дате отправления: