From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com> |
Subject: | Re: proposal: session server side variables |
Date: | 2017-01-04 17:34:01 |
Message-ID: | CAFj8pRB4E=jeFS1H-eL-ezVB2c8JOXV+wESBcAfYWy8MjUzUag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-01-04 17:58 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-01-04 17:46:36 | Re: Logical Replication WIP |
Previous Message | Robert Haas | 2017-01-04 17:17:08 | Re: Cluster wide option to control symbol case folding |