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
Mahendra Singh Thalor <mahi6run@gmail.com>
From: Mahendra Singh Thalor <mahi6run@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-01-10T12:24:21Z
Lists: pgsql-bugs, pgsql-hackers
On Fri, 10 Jan 2020 at 16:37, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Jan 10, 2020 at 05:01:25PM +0900, Michael Paquier wrote:
> > This makes me wonder how much we should try to outsmart somebody which
> > puts the catalogs in such a inconsistent state. Hmm. Perhaps at the
> > end autovacuum should just ignore such entries and just don't help the
> > user at all as this also comes with its own issues with the storage
> > level as well as smgr.c uses rd_backend. And if the user plays with
> > temporary namespaces like that with superuser rights, he likely knows
> > what he is doing. Perhaps not :D, in which case autovacuum may not be
> > the best thing to decide that. I still think we should make the log
> > of autovacuum.c for orphaned relations more careful with its coding
> > though, and fix it with the previous patch. The documentation of
> > isTempNamespaceInUse() could gain in clarity, just a nit from me while
> > looking at the surroundings. And actually I found an issue with its
> > logic, as the routine would not consider a temp namespace in use for a
> > session's own MyBackendId. As that's only used for autovacuum, this
> > has no consequence, but let's be correct in hte long run.
> >
> > And this gives the attached after a closer lookup. Thoughts?
>
> Thinking more about it, this has a race condition if a temporary
> schema is removed after collecting the OIDs in the drop phase. So the
> updated attached is actually much more conservative and does not need
> an update of the log message, without giving up on the improvements
> done in v11~. In 9.4~10, the code of the second phase relies on
> GetTempNamespaceBackendId() which causes an orphaned relation to not
> be dropped in the event of a missing namespace. I'll just leave that
> alone for a couple of days now..
> --
Thanks for the patch. I am not getting any crash but \d is not showing
any temp table if we drop temp schema and create again temp table.
postgres=# create temporary table test1 (a int);
CREATE TABLE
postgres=# \d
List of relations
Schema | Name | Type | Owner
-----------+-------+-------+----------
pg_temp_3 | test1 | table | mahendra
(1 row)
postgres=# drop schema pg_temp_3 cascade ;
NOTICE: drop cascades to table test1
DROP SCHEMA
postgres=# \d
Did not find any relations.
postgres=# create temporary table test1 (a int);
CREATE TABLE
postgres=# \d
Did not find any relations.
postgres=#
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com
Commits
-
Avoid failure if autovacuum tries to access a just-dropped temp namespace.
- d7684c38a5e9 12.3 landed
- 80d76be51cfb 13.0 landed
- 7ea20a2bc6bd 11.8 landed
-
Revert "Forbid DROP SCHEMA on temporary namespaces"
- b83ba2e6e706 9.4.26 landed
- 86949c2f1207 9.5.21 landed
- 50174b70e779 9.6.17 landed
- 0c046f816902 10.12 landed
- 789bc293b341 11.7 landed
- a1c003e5ff82 12.2 landed
- 65192e02441c 13.0 landed
-
Forbid DROP SCHEMA on temporary namespaces
- 898e0c650097 9.4.26 landed
- 12cb5478a2a4 9.5.21 landed
- cb6f94a5219d 9.6.17 landed
- f1958351eae2 10.12 landed
- 786540085dbd 11.7 landed
- 1dd88201ad6e 12.2 landed
- a052f6cbb84e 13.0 landed
-
Make autovacuum more aggressive to remove orphaned temp tables
- 246a6c8f7b23 12.0 cited
-
Code review for early drop of orphaned temp relations in autovacuum.
- dafa0848da11 10.0 cited