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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Mahendra Singh <mahi6run@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-08T00:44:09Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

On Tue, Jan 07, 2020 at 01:06:08PM -0500, Tom Lane wrote:
> I still agree with Robert that a052f6c is a bad idea.  It's not the case
> that that's blocking "any connected user" from causing an issue.  The
> temp schemas are always owned by the bootstrap superuser, so only a
> superuser could delete them.  All that that patch is doing is preventing
> superusers from doing something that they could reasonably wish to do,
> and that is perfectly safe when there's not concurrent usage of the
> schema.  We are not normally that nanny-ish, and the case for being so
> here seems pretty thin.

Okay, I am running out of arguments then, so attached is a patch to
address things.  I would also prefer if we keep the relation name in
the log even if the namespace is missing.
--
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.