BUG #15646: Inconsistent behavior for current_setting/set_config

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: kes-kes(at)yandex(dot)ru
Subject: BUG #15646: Inconsistent behavior for current_setting/set_config
Date: 2019-02-20 16:10:56
Message-ID: 15646-0d3caee9f6266f60@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

The following bug has been logged on the website:

Bug reference: 15646
Logged by: Eugen Konkov
Email address: kes-kes(at)yandex(dot)ru
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(at)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)

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hans Buschmann 2019-02-20 16:17:08 AW: BUG #15641: Autoprewarm worker fails to start on Windows with huge pages in use Old PostgreSQL community/pgsql-bugs x
Previous Message Daniel Verite 2019-02-20 14:38:23 Re: BUG #15645: \COPY command not printing output in batch mode

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-02-20 16:16:51 Re: list append syntax for postgresql.conf
Previous Message Robert Haas 2019-02-20 16:09:19 Re: propagating replica identity to partitions