| From: | Mahendra Singh Thalor <mahi6run(at)gmail(dot)com> | 
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| 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 | 
| Date: | 2020-01-10 12:24:21 | 
| Message-ID: | CAKYtNAodw-icDF1ZMue2OL0buX-wbOYXgo+fQ+uiB-L8cOtmsA@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers | 
On Fri, 10 Jan 2020 at 16:37, Michael Paquier <michael(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Meskes | 2020-01-10 12:43:38 | Re: BUG #16200: returned data from ESQL/C FETCH is trampling outside assigned memory for CHAR column | 
| Previous Message | Matthias Apitz | 2020-01-10 11:55:39 | Re: BUG #16200: ESQL/C FETCH of CHAR data delivers to much data for UTF-8 | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2020-01-10 12:24:34 | Re: [Proposal] Global temporary tables | 
| Previous Message | Peter Eisentraut | 2020-01-10 12:23:21 | Re: our checks for read-only queries are not great |