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:
SET enable_seqscan TO off;
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:
custom_variable_classes = "foo"
foo.var = 3
In a session we do:
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:
So what should happen?
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.
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
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
In this point of view I think interpretation 2 is correct.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not