Re: postmaster errors with index on temp table? - Mailing list pgsql-hackers

> At 09:27 10/07/00 -0400, Bruce Momjian wrote:
> >> >Yikes, I never looked in the postmaster log to see this.
> >>
> >> As Tom Lane said, it's non-fatal, and probably not important, but I worried
> >> me. I'll see if I can see the cause while I wait for people to test my new
> >> pg_dump with BLOB support.
> >
>
> I've had a look at temprel.c, and remove_all_temp_relations has the following:
>
>                 if (temp_rel->relkind != RELKIND_INDEX)
>                 {
>                         char            relname[NAMEDATALEN];
>
>                         /* safe from deallocation */
>                         strcpy(relname, temp_rel->user_relname);
>                         heap_drop_with_catalog(relname, allowSystemTableMods);
>                 }
>                 else
>                         index_drop(temp_rel->relid);
>
> But, when a temp rel is dropped it seems that heap_drop_with_catalog also
> drops the indexes, so the error occurs when index_drop is called (at least
> I think this is the case). Certainly commenting out the last two lines
> *seems* to work.
>
> These lines were changed in rev 1.18 from 'heap_destroy*' calls to
> 'heap_drop' calls...did 'heap_destroy*' also delete related objects as
> heap_drop* now does?

Not sure why I introduced that bug in 1.18.  Your suggestion was 100%
correct.  I have applied the following patch.

Thanks for finding that.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
? config.log
? config.cache
? config.status
? GNUmakefile
? src/GNUmakefile
? src/Makefile.custom
? src/Makefile.global
? src/log
? src/crtags
? src/backend/postgres
? src/backend/catalog/global.bki
? src/backend/catalog/global.description
? src/backend/catalog/template1.bki
? src/backend/catalog/template1.description
? src/backend/port/Makefile
? src/bin/initdb/initdb
? src/bin/initlocation/initlocation
? src/bin/ipcclean/ipcclean
? src/bin/pg_ctl/pg_ctl
? src/bin/pg_dump/pg_dump
? src/bin/pg_dump/pg_restore
? src/bin/pg_dump/pg_dumpall
? src/bin/pg_id/pg_id
? src/bin/pg_passwd/pg_passwd
? src/bin/pgaccess/pgaccess
? src/bin/pgtclsh/Makefile.tkdefs
? src/bin/pgtclsh/Makefile.tcldefs
? src/bin/pgtclsh/pgtclsh
? src/bin/pgtclsh/pgtksh
? src/bin/psql/psql
? src/bin/scripts/createlang
? src/include/config.h
? src/interfaces/ecpg/lib/libecpg.so.3.1.1
? src/interfaces/ecpg/preproc/ecpg
? src/interfaces/libpgeasy/libpgeasy.so.2.1
? src/interfaces/libpgtcl/libpgtcl.so.2.1
? src/interfaces/libpq/libpq.so.2.1
? src/pl/plpgsql/src/libplpgsql.so.1.0
? src/pl/tcl/Makefile.tcldefs
? src/test/regress/GNUmakefile
Index: src/backend/utils/cache/temprel.c
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/cache/temprel.c,v
retrieving revision 1.26
diff -c -r1.26 temprel.c
*** src/backend/utils/cache/temprel.c    2000/07/04 06:11:47    1.26
--- src/backend/utils/cache/temprel.c    2000/07/11 15:02:48
***************
*** 107,112 ****
--- 107,113 ----

          next = lnext(l);        /* do this first, l is deallocated */

+         /* Indexes are dropped during heap drop */
          if (temp_rel->relkind != RELKIND_INDEX)
          {
              char        relname[NAMEDATALEN];
***************
*** 115,122 ****
              strcpy(relname, temp_rel->user_relname);
              heap_drop_with_catalog(relname, allowSystemTableMods);
          }
-         else
-             index_drop(temp_rel->relid);

          l = next;
      }
--- 116,121 ----
***************
*** 235,241 ****
   *
   * We also reject an attempt to rename a normal table to a name in use
   * as a temp table name.  That would fail later on anyway when rename.c
!  * looks for a rename conflict, but we can give a more specific error
   * message for the problem here.
   *
   * It might seem that we need to check for attempts to rename the physical
--- 234,240 ----
   *
   * We also reject an attempt to rename a normal table to a name in use
   * as a temp table name.  That would fail later on anyway when rename.c
!  * looks for a rename conflict, but we can give a more specific error
   * message for the problem here.
   *
   * It might seem that we need to check for attempts to rename the physical