Re: proposal: session server side variables (fwd)

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: session server side variables (fwd)
Date: 2017-01-08 09:20:59
Message-ID: alpine.DEB.2.20.1701081007440.10378@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2017-01-08 09:36:32 Re: [PATCH] Generic type subscription
Previous Message Joel Jacobson 2017-01-08 09:09:15 RustgreSQL