PostgreSQL Bugs

Collected from the PG bugs email list.

Bug ID15646
PG Version10.4
OS(Debian 10.4-2.pgdg90+1)
Opened2019-02-20 16:10:56+00
Reported byEugen Konkov
StatusNew

Body of first available message related to this bug follows.

The following bug has been logged on the website:

Bug reference:      15646
Logged by:          Eugen Konkov
Email address:      (redacted)
PostgreSQL version: 10.4
Operating system:   (Debian 10.4-2.pgdg90+1)
Description:        

Hi.

[documentation](https://www.postgresql.org/docs/11/functions-admin.html#FUNCTIONS-ADMIN-SET)
describes that:

>set_config sets the parameter setting_name to new_value. If is_local is
true, the new value will only apply to the current transaction.

Thus if I rollback transaction original value should be available.

But current behavior returns empty string instead of NULL (the initial
value) after transaction is rolled back. When I restart session, NULL is
returned again as it is expected.
( I expect NULL just because 'my.app_period' is not configuration variable
is not defined yet. The documentation (link provided above) does not cover
what should be returned)

How to reproduce steps:
$ make dbshell
psql -h databases -p 5433 -U tucha tucha ||:
psql (11.1 (Ubuntu 11.1-1.pgdg16.04+1), server 10.4 (Debian
10.4-2.pgdg90+1))
Type "help" for help.

We start a new session and check setting value before transaction. It is
NULL:
tucha=> select current_setting( 'my.app_period', true ) is null;
 ?column? 
----------
 t
(1 row)

We start transaction and change the setting value:
tucha=> begin;
BEGIN
tucha=> select set_config( 'my.app_period', 'some value', true );
 set_config 
------------
 some value
(1 row)

We can see that value is changed. It is NOT NULL:
tucha=> select current_setting( 'my.app_period', true ) is null;
 ?column? 
----------
 f
(1 row)

tucha=> select current_setting( 'my.app_period', true );
 current_setting 
-----------------
 some value
(1 row)

Here I finish transaction (it has no matter how: commit/rollback):
tucha=> rollback;
ROLLBACK

Here we can see that setting value is different from value that was before
transaction
tucha=> select current_setting( 'my.app_period', true ) is null;
 ?column? 
----------
 f
(1 row)

tucha=> \q


When I restart session I get NULL again (as expected):
kes@work ~/t $ make dbshell
psql -h databases -p 5433 -U tucha tucha ||:
psql (11.1 (Ubuntu 11.1-1.pgdg16.04+1), server 10.4 (Debian
10.4-2.pgdg90+1))
Type "help" for help.

tucha=> select current_setting( 'my.app_period', true ) is null;
 ?column? 
----------
 t
(1 row)


My database version:
tucha=> select version();
                                                             version        
             
------------------------------------------------------------------------------------------
 PostgreSQL 10.4 (Debian 10.4-2.pgdg90+1) on x86_64-pc-linux-gnu, compiled
by gcc (Debian 
(1 row)

Messages

DateAuthorSubject
2019-02-20 16:10:56+00PG Bug reporting formBUG #15646: Inconsistent behavior for current_setting/set_config
2019-02-20 17:01:47+00Joe ConwayRe: BUG #15646: Inconsistent behavior for current_setting/set_config
2019-02-20 17:11:15+00Tom LaneRe: BUG #15646: Inconsistent behavior for current_setting/set_config
2019-02-20 17:32:20+00"David G(dot) Johnston"Re: BUG #15646: Inconsistent behavior for current_setting/set_config
2019-02-20 18:06:07+00Jerry SievertRe: BUG #15646: Inconsistent behavior for current_setting/set_config