Re: Regression caused by recent change to initdb?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Regression caused by recent change to initdb?
Дата
Msg-id 24451.1452091825@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Regression caused by recent change to initdb?  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Regression caused by recent change to initdb?  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
Amit Langote <Langote_Amit_f8@lab.ntt.co.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Shulgin, Oleksandr"
Дата:
Сообщение: Re: Add schema-qualified relnames in constraint error messages.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Comment typo in namespace.c