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

From Michael Paquier
Subject Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema
Date
Msg-id 20200108004409.GA3413@paquier.xyz
Whole thread Raw
In response to 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>)
Responses 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>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: xact_start for walsender & logical decoding not updated
Next
From: Tom Lane
Date:
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