Обсуждение: Re: [HACKERS] proposal: session server side variables (fwd)
<Argh, wrong sender again, sorry [again] for the repost. I must tweak my mail client configuration...> >>> Good. So we seem to agree that GUCS are transactional? > > I'm surprised, I never knew this. I must admit that it was also a (good) surprise for me. The documentation says it: """ If SET (or equivalently SET SESSION) is issued within a transaction that is later aborted, the effects of the SET command disappear when the transaction is rolled back. Once the surrounding transaction is committed, the effects will persist until the end of the session, unless overridden by another SET. """ But I have not found anything clear about user-defined parameters. -- Fabien.
On Thu, Jan 5, 2017 at 11:45:24AM +0100, Fabien COELHO wrote: > > <Argh, wrong sender again, sorry [again] for the repost. > I must tweak my mail client configuration...> > > >>>Good. So we seem to agree that GUCS are transactional? > > > >I'm surprised, I never knew this. > > I must admit that it was also a (good) surprise for me. > > The documentation says it: > > """ > If SET (or equivalently SET SESSION) is issued within a transaction that is > later aborted, the effects of the SET command disappear when the transaction > is rolled back. Once the surrounding transaction is committed, the effects > will persist until the end of the session, unless overridden by another SET. > """ > > But I have not found anything clear about user-defined parameters. Uh, I think it is a missing feature, i.e.: https://wiki.postgresql.org/wiki/Todo#AdministrationHave custom variables be transaction-safe https://www.postgresql.org/message-id/4B577E9F.8000505@dunslane.net -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Hello Bruce, >>>>> Good. So we seem to agree that GUCS are transactional? > > Uh, I think it is a missing feature, i.e.: > > https://wiki.postgresql.org/wiki/Todo#Administration > Have custom variables be transaction-safe > https://www.postgresql.org/message-id/4B577E9F.8000505@dunslane.net Hmmm, that is a subtle one:-) After more testing, the current status is that the values of existing user-defined parameters is cleanly transactional, as already tested: fabien=# SET x.x = 'before'; fabien=# BEGIN; fabien=# SET x.x = 'inside'; fabien=# ROLLBACK; fabien=# SHOW x.x; -- 'before' This is what I meant by "GUCs are transactional". However, as you point out, the existence of the parameter is not: If it is created within an aborted transaction then it still exists afterwards: fabien=# SHOW z.z; ERROR: unrecognized configuration parameter "z.z" fabien=# BEGIN; fabien=# SET z.z = 'yep'; fabien=#ROLLBACK; fabien=# SHOW z.z; -- no error, empty string shown So GUCs are... half-transactional? :-) From the security-related use case perspective, this half transactionality is enough, but it is not very clean. Does not look like a very big issue to fix, it just seems that nobody bothered in the last 6 years... -- Fabien.