Re: [HACKERS] proposal: session server side variables (fwd)
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables (fwd) |
Дата | |
Msg-id | alpine.DEB.2.20.1701081007440.10378@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: session server side variables (fwd) (Fabien COELHO <coelho@cri.ensmp.fr>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: