From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Regression caused by recent change to initdb? |
Date: | 2016-01-06 14:50:25 |
Message-ID: | 24451.1452091825@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> writes:
> On 2016/01/06 17:32, Amit Langote wrote:
>> 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:
>> ...
>> These seem to be leftovers of activities of initdb.c's setup_description()
>> and setup_collaction().
> I noticed these leftovers are not present in template1.
Ah, right: they get deleted from template1 correctly when the
initdb-driven session shuts down. But because of the merger into a single
session, they're still there at the instant that we clone template1 into
template0 and postgres databases, and there is nothing to remove them from
there.
The minimum-change way to deal with it would be to explicitly DROP those
tables when we're done with them.
A possibly slightly less fragile answer is to run two sessions, the
second of which *only* processes the DB copying steps.
Neither of these answers seems all that clean to me...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-01-06 14:51:50 | Re: Comment typo in namespace.c |
Previous Message | Shulgin, Oleksandr | 2016-01-06 14:02:34 | Re: Add schema-qualified relnames in constraint error messages. |