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>, 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-04 13:57:15 |
Message-ID: | CAFj8pRCUmbsWiMrYv0hyZtZE-0tySMGxfH3V6nHOTFBBgZP2Sw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-01-04 14:33 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:
>
> An alternative is to implement sub (nested) transactions, like Oracle and
>> MS SQL Server... but that would be quite some work.
>>
>
> As a complement, a search showed that IBM DB2, cited as a reference by
> Pavel, has AUTONOMOUS transactions, which looks pretty much the same thing
> as nested transactions. The documentation presents an interesting use
> security-related use case:
>
I had on my mind autonomous transactions.
>
> https://www.ibm.com/developerworks/data/library/techarticle/
> dm-0907autonomoustransactions/
>
> The idea is that an application must record an attempt to access a data
> even if the attempt fails and is rolled-back.
>
Now we can this feature emulate with dblink, and there are patches in
commitfest based on background workers, and emulation will be cheaper.
Regards
Pavel
>
> This feature used carefully within an appropriate pattern would allow to
> ensure that if the setup transaction fails then the session status is
> FALSE. One possible inconsistency which may arise with sub xacts is that
> the status may stay FALSE while the setup has succeeded, however this on
> the safe side wrt to the security use case.
>
> --
> Fabien.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-01-04 13:57:53 | Re: increasing the default WAL segment size |
Previous Message | Peter Eisentraut | 2017-01-04 13:53:57 | Re: pg_sequence catalog |