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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Mahendra Singh <mahi6run@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-07T18:06:08Z
Lists: pgsql-bugs, pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 6, 2020 at 7:22 PM Michael Paquier <michael@paquier.xyz> wrote:
>> For the second one, I would really wish that we keep the restriction
>> put in place by a052f6c until we actually figure out how to make the
>> operation safe in the ways we want it to work because this puts
>> the catalogs into an inconsistent state for any object type able to
>> use a temporary schema, like functions, domains etc. for example able
>> to use "pg_temp" as a synonym for the temp namespace name.  And any
>> connected user is able to do that.

> So what?

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.

			regards, tom lane

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.