Re: guc fallback to default

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.

The second interpretation is based on the fact that you can create a custom
variable by just assigning a value to it. So if you have
custom_variable_classes = "foo", foo.<anythinghere> is a valid variable.

Actually I think we could go either way, it seems to be a really rare corner
case. I'm fine with either way.

Note that if we deleted the line with "custom_variable_classes = foo" from
the previous example as well, it is clear that the transaction should fail.

Joachim

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