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>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com> |
Subject: | Re: proposal: session server side variables |
Date: | 2017-01-03 16:33:25 |
Message-ID: | alpine.DEB.2.20.1701031659410.16727@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
****** PLEASE ******
COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN
REPLYING IN THE THREAD?
****** THANKS ******
>> [...] Then B believes that A succeeded, which is not the case.
>
> No, just your design is unhappy
> SELECT A(..)
> SET SESSION VARIABLE status_ok = false;
> -- do all, if fails there,
> -- then follow line fails too, or never be executed
> SET SESSION VARIABLE status_ok = true;
My point is that there is no commit in this code, the commit is performed
*AFTER* the last set session, and it mail fail then.
> or
>
> SET SESSION VARIABLE status_ok = true
> TRY
> do something
> CATCH
> ROLLBACK
> SET SESSION VARIABLE status_ok = false
>
> Both I can do in current PL
The fact that "do something" worked does not preclude the overall
transaction to work and to revert "do something" and let status_ok as
true.
>> The key issue is that the final status (commit or rollback) of the
>> containing transaction cannot be known from within the function, so the
>> session variables cannot reflect this status.
>>
>> So somehow the status_ok variable must be (1) rolledback to previous value
>> or (2) removed (3) set to FALSE or (4) set to NULL. It cannot be TRUE if A
>> containing transactions has failed for the security as I understand it.
>>
> you don't need do rollback variable if you write well A
My point is that A may still fail *after* setting the variable, because it
is in a transaction.
> If you use patterns that I wrote - the security context will be valid
> always.
No: This pattern assumes that operations started in the "TRY" zone cannot
fail later on... This assumption is false because of possible deferred
triggers for instance. See attached example:
NOTICE: SET secured = FALSE
NOTICE: SET secured = TRUE
ERROR: insert or update on table "log" violates foreign key constraint "log_sid_fkey"
DETAIL: Key (sid)=(3) is not present in table "stuff".
The error occurs after secured has been set to TRUE.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
deferred.sql | application/x-sql | 846 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-01-03 16:34:50 | Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal |
Previous Message | Robert Haas | 2017-01-03 16:24:25 | Re: increasing the default WAL segment size |