Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Mahendra Singh <mahi6run@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-27T09:06:04Z
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@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

Commits

  1. Avoid failure if autovacuum tries to access a just-dropped temp namespace.

  2. Revert "Forbid DROP SCHEMA on temporary namespaces"

  3. Forbid DROP SCHEMA on temporary namespaces

  4. Make autovacuum more aggressive to remove orphaned temp tables

  5. Code review for early drop of orphaned temp relations in autovacuum.