Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id CAFj8pRBskFDYN7kX3MX3i45qEXrR=BFPoS4MoeXWdo3WcUro5A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


2017-01-03 18:52 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:

****** PLEASE ******
 COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN
 REPLYING IN THE THREAD?
****** THANKS ****** 

Hmmm. It seems that you can't. You should, really.

I am sorry - The gmail client mask me these parts. I'll clean it more
 


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:

ok .. it is pretty artificial, but ok.

Good. We seem to agree that some kind of transactional support is needed for the use case, which is pretty logical.

In this case the reset to NULL on ROLLBACK should be enough.

Probably.

So I expect that you are going to update your proposal somehow to provide some transactional properties.

Note that if you have some mecanism for doing a NULL on rollback, then why not just keep and reset the previous value if needed? This just means that you have a transactional variable, which is fine from my point of view. As I already wrote, session variable are memory only, so transactional does not involve costs such as WAL.

There is not cost such as WAL - in any update, you have to check if this is first update in transaction, and if it is, then you have to create new memory context and create new callback that will be evaluated on rollback. 

Probably there is not big difference between RESET and UNDO in complexity of implementation. You have to do partial implementation of MVCC. No simple code.

 

Also note that user-defined GUCs already implements the transactional property, so probably the mecanism is already available and can be reused.

GUC are stack based  - the value doesn't depends if transaction was successful or not.


--
Fabien.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Cluster wide option to control symbol case folding
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Update copyright for 2017