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


---------------------------(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
      match

Reply via email to