From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Mahendra Singh <mahi6run(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema |
Date: | 2019-12-27 09:06:04 |
Message-ID: | 20191227090604.GA540891@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Juan José Santamaría Flecha | 2019-12-27 12:41:03 | Re: pg_upgrade |
Previous Message | vignesh C | 2019-12-27 08:20:15 | Re: Reorderbuffer crash during recovery |
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2019-12-27 09:15:33 | Re: Expose lock group leader pid in pg_stat_activity |
Previous Message | Sergei Kornilov | 2019-12-27 09:01:21 | Re: Expose lock group leader pid in pg_stat_activity |