Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema
Дата
Msg-id 20191227090604.GA540891@paquier.xyz
обсуждение исходный текст
Ответ на Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp table schema  (Mahendra Singh <mahi6run@gmail.com>)
Ответы Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp table schema  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Dec 27, 2019 at 12:33:03AM +0530, Mahendra Singh wrote:
> On Thu, 26 Dec 2019 at 23:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> No, we can't, because the particular temp namespace used by a given
>> session isn't stable.

And I'd prefer keep the name of the namespace in the error message,
because the information is helpful.

>>> I thought that auto_vacuum wlll drop all
>>> the temp table schema but it is not drooping.
>>
>> Generally speaking, once a particular pg_temp_N schema exists it's
>> never dropped, just recycled for use by subsequent sessions.
>
> Okay. Understood. Thanks for clarification.

Please see RemoveTempRelations() for the details, which uses
PERFORM_DELETION_SKIP_ORIGINAL to avoid a drop of the temp schema, and
just work on all the objects the schema includes.

And committed down to 9.4.  We use much more "temporary schema" in
error messages actually, so I have switched to that.
--
Michael

Вложения

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

Предыдущее
От: Sergei Kornilov
Дата:
Сообщение: Re: Expose lock group leader pid in pg_stat_activity
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Expose lock group leader pid in pg_stat_activity