Regression caused by recent change to initdb? - Mailing list pgsql-hackers

From Amit Langote
Subject Regression caused by recent change to initdb?
Date
Msg-id 568CD12C.5060706@lab.ntt.co.jp
Whole thread Raw
Responses Re: Regression caused by recent change to initdb?  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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_1pg_toast_11817_index |
pg_toast_temp_1pg_toast_11822      | pg_toast_temp_1pg_toast_11822_index | pg_toast_temp_1pg_toast_11827       |
pg_toast_temp_1pg_toast_11827_index| pg_toast_temp_1tmp_pg_description   | pg_temp_1tmp_pg_shdescription |
pg_temp_1tmp_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





pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: WIP: Covering + unique indexes.
Next
From: Andreas Karlsson
Date:
Subject: Re: Making tab-complete.c easier to maintain