| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Regression caused by recent change to initdb? |
| Date: | 2016-01-06 08:32:44 |
| Message-ID: | 568CD12C.5060706@lab.ntt.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I stumbled upon a possibly strange behavior which may be related to recent
initdb changes. For a freshly initdb'd cluster, the following looks fishy:
postgres=# SELECT relname, relnamespace::regnamespace FROM pg_class
WHERE relnamespace != 'pg_catalog'::regnamespace
AND relnamespace != 'pg_toast'::regnamespace
AND relnamespace != 'information_schema'::regnamespace;
relname | relnamespace
----------------------+-----------------
pg_toast_11817 | pg_toast_temp_1
pg_toast_11817_index | pg_toast_temp_1
pg_toast_11822 | pg_toast_temp_1
pg_toast_11822_index | pg_toast_temp_1
pg_toast_11827 | pg_toast_temp_1
pg_toast_11827_index | pg_toast_temp_1
tmp_pg_description | pg_temp_1
tmp_pg_shdescription | pg_temp_1
tmp_pg_collation | pg_temp_1
(10 rows)
These seem to be leftovers of activities of initdb.c's setup_description()
and setup_collaction(). Interestingly, they disappear after performing the
following steps:
0. Stop the server
1. Connect to the database in --single mode, create a temp table, exit.
2. Log back into the database in normal mode and execute the same query.
The behavior seems to be as of commit c4a8812cf (Use just one
standalone-backend session for initdb's post-bootstrap steps). Is this a
regression?
Thanks,
Amit
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Karlsson | 2016-01-06 08:59:48 | Re: Making tab-complete.c easier to maintain |
| Previous Message | David Rowley | 2016-01-06 07:55:22 | Re: WIP: Covering + unique indexes. |