From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
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 16:58:05 |
Message-ID: | alpine.DEB.2.20.1701041748410.22281@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-01-04 16:58:55 | Re: [PATCH] PostgresNode.pm enhancements, pg_lsn helper, and some more recovery tests |
Previous Message | Stephen Frost | 2017-01-04 16:49:58 | Re: [PATCH] Reload SSL certificates on SIGHUP |