Thread

1. New VACUUM FULL crashes on temp relations

   Simon Riggs <simon@2ndquadrant.com> — 2010-02-01T08:29:40Z

   TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File:
   "pg_type.c", Line: 658)
   
   Test case attached, repeated, consistent failure on CVS HEAD.
   
   Crash occurs with either CLUSTER or VACUUM FULL.
   
   Passed on without further investigation.
   
   -- 
    Simon Riggs           www.2ndQuadrant.com
   

2. Re: New VACUUM FULL crashes on temp relations

   Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> — 2010-02-02T00:45:19Z

   Simon Riggs <simon@2ndQuadrant.com> wrote:
   
   > TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File:
   > "pg_type.c", Line: 658)
   > 
   > Test case attached, repeated, consistent failure on CVS HEAD.
   
   I see the same assertion failure on 8.4.2, too.
   I'll investigating it...
   
   -- minimum reproducible pattern
   drop table if exists footemp;
   create temp table footemp (col1 serial, col2 text);
   create index footemp_col1_idx on footemp (col1);
   cluster footemp using footemp_col1_idx;
   
   Regards,
   ---
   Takahiro Itagaki
   NTT Open Source Software Center
   
   
   
   

3. Re: New VACUUM FULL crashes on temp relations

   Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> — 2010-02-02T05:28:32Z

   Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> wrote:
   
   > > TRAP: FailedAssertion("!(typeNamespace == typ->typnamespace)", File:
   > > "pg_type.c", Line: 658)
   
   It comes from swapping toast relations:
     DEBUG:  typeNamespace mismatch: 99 (pg_toast) vs. 16386 (pg_toast_temp_2)
   
   AFAICS, the assertion is broken, but the code is correct. We just need to
   adjust the expression in the assertion.
   Patch attached, including new regression tests for clustering a temp table.
   
   > I see the same assertion failure on 8.4.2, too.
   
   I'll go for backpatcting if the attached fix is correct. Comments welcome.
   
   Regards,
   ---
   Takahiro Itagaki
   NTT Open Source Software Center
   
   

4. Re: New VACUUM FULL crashes on temp relations

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-02T16:57:14Z

   Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> writes:
   > AFAICS, the assertion is broken, but the code is correct. We just need to
   > adjust the expression in the assertion.
   
   I think this is 100% wrong.  Toast tables shouldn't be changing
   namespace either; which means you broke something somewhere else.
   
   			regards, tom lane
   
   

5. Re: New VACUUM FULL crashes on temp relations

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-02T18:55:31Z

   I wrote:
   > Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> writes:
   >> AFAICS, the assertion is broken, but the code is correct. We just need to
   >> adjust the expression in the assertion.
   
   > I think this is 100% wrong.  Toast tables shouldn't be changing
   > namespace either; which means you broke something somewhere else.
   
   After tracing through it, the problem is that rebuild_relation() assumes
   toast tables are always in PG_TOAST_NAMESPACE; which has not been true
   since 8.3.  CLUSTER has been renaming temp toast tables into the wrong
   namespace right along.  Without the assert to call attention to it, who
   knows how long it would've taken to notice :-(
   
   Will fix.
   
   			regards, tom lane
   
   

6. Re: New VACUUM FULL crashes on temp relations

   Tom Lane <tgl@sss.pgh.pa.us> — 2010-02-02T19:16:17Z

   I wrote:
   > After tracing through it, the problem is that rebuild_relation() assumes
   > toast tables are always in PG_TOAST_NAMESPACE; which has not been true
   > since 8.3.  CLUSTER has been renaming temp toast tables into the wrong
   > namespace right along.  Without the assert to call attention to it, who
   > knows how long it would've taken to notice :-(
   
   No, on closer inspection the bug was introduced here:
   http://archives.postgresql.org/pgsql-committers/2008-10/msg00118.php
   so 8.3 was OK.  In a non-asserting build the only consequence would have
   been that checks for conflicting names were done in the wrong namespace.
   Given the improbability of a conflict, we could have gone a very long
   time before noticing the problem.  But it was still wrong.
   
   			regards, tom lane