Joachim Wieland wrote:
> I'm working again on the patch for making guc variables fall back to their
> default value if they get removed (or commented) in the configuration file.
>
> There is still an issue with custom variables that needs discussion.
>
> Remember that for regular variables we have the following semantics:
>
> BEGIN;
> SET enable_seqscan TO off;
> COMMIT;
>
> The effect of the commit on the variable is that the variable is set to the
> specified value from then on in that session (outside of the transaction).
>
> This is also valid for custom variables. But those can be removed from the
> configuration file while all other variables can not (all other variables
> fall back to some default value).
>
> Imagine the following example:
>
> Configuration file:
> custom_variable_classes = "foo"
> foo.var = 3
>
> In a session we do:
> BEGIN;
> SET foo.var TO 5;
>
> With the transaction still being open, we remove the definition of foo.var
> from the configuration file and send SIGHUP.
>
> Then we commit the transaction:
>
> COMMIT;
>
> So what should happen?
>
> Interpretation 1:
> foo.var got deleted. COMMIT can not assure that the value of
> foo.var gets applied, because foo.var does not exist anymore.
> The transaction fails.
>
> Interpretation 2:
> The foo.var variable from the configuration file got deleted but the
> SET command in the transaction defines a new variable which is
> valid, because we still have custom_variable_classes = "foo". The
> transaction succeeds.
>
Current status is when you change variable value in conf file, it
changes inside all transaction also. However if SET command is used then
value is override and any change in conf file does not affect this
variable. SET command has higher priority and override all changes in
postgresql.conf.
In this point of view I think interpretation 2 is correct.
Zdenek
