BUG #16214: Settings is not copy - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #16214: Settings is not copy
Date
Msg-id 16214-aee287cfd82762b4@postgresql.org
Whole thread Raw
Responses Re: BUG #16214: Settings is not copy  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
The following bug has been logged on the website:

Bug reference:      16214
Logged by:          Michail Shurutov
Email address:      shurutov@gmail.com
PostgreSQL version: 11.6
Operating system:   Gentoo, RHEL
Description:

I downloaded and ulpoaded into local PostgreSQL instance demo database from
Postgres Professional: https://postgrespro.ru/education/demodb
Than I made copy as "CREATE DATABASE demo_small template demo", after this I
noticed:
postgres=# \c demo
   
You are now connected to database "demo" as user "postgres".
   
demo=# select name,setting from pg_settings where name = 'search_path';
   
    name     |     setting
   
-------------+------------------
   
 search_path | bookings, public
   
(1 row)
   

   
demo=# \c demo_small
   
You are now connected to database "demo_small" as user "postgres".
   
demo_small=# select name,setting from pg_settings where name =
'search_path';   
    name     |     setting
   
-------------+-----------------
   
 search_path | "$user", public
   
(1 row)
   

   
demo_small=# \q

Parameter "search_path" was not copied.

And command "ALTER DATABASE" was not in included into dump made by
pg_dump:
mshurutov@desktop fromarch $ sudo -u postgres pg_dump -C demo_small >
/var/tmp/demo_small.sql
mshurutov@desktop fromarch $ grep "ALTER DATABASE" demo-small-20170815.sql
ALTER DATABASE demo SET search_path = bookings, public;
ALTER DATABASE demo SET bookings.lang = ru;
mshurutov@desktop fromarch $ grep "ALTER DATABASE" /var/tmp/demo_small.sql

ALTER DATABASE demo_small OWNER TO postgres;
mshurutov@desktop fromarch $


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16213: segfault when running a query
Next
From: Tom Lane
Date:
Subject: Re: SQL/PostgreSQL - Error observed in the QUERY not caught by the “EXCEPTION” block in the stored procedure