Hi all,

It seems that in PostgreSQL 8.2.4 (don't know exactly when the change 
was made) TRUNCATE resets relhasindex to the appropriate value. This 
has the effect that if the TRUNCATE in preparetableforcopy succeeds, 
relhasindex is set back to true, and the indexes are updated during 
the copy, with the well known performance hit that goes with it.

Attached patch apparently fixes the problem (just set relhasindex to 
false _after_ the TRUNCATE):

--- slony1_funcs.v81.sql.orig   Thu Jul 26 16:11:36 2007
+++ slony1_funcs.v81.sql        Thu Jul 26 16:12:28 2007
@@ -40,19 +40,23 @@
         end if;

         -- ----
+       -- Try using truncate to empty the table and fallback to
+       -- delete on error.
+       -- ----
+       execute ''truncate '' || @NAMESPACE at .slon_quote_input(v_tab_fqname);
+       raise notice ''truncate of % succeeded'', v_tab_fqname;
+
+       -- ----
         -- Setting pg_class.relhasindex to false will cause copy not to
         -- maintain any indexes. At the end of the copy we will reenable
         -- them and reindex the table. This bulk creating of indexes is
         -- faster.
+       --
+       -- This must be done _after_ the truncate as since 8.2 truncate
+       -- resets relhasindex!
         -- ----
         update pg_class set relhasindex = ''f'' where oid = v_tab_oid;

-       -- ----
-       -- Try using truncate to empty the table and fallback to
-       -- delete on error.
-       -- ----
-       execute ''truncate '' || @NAMESPACE at .slon_quote_input(v_tab_fqname);
-       raise notice ''truncate of % succeeded'', v_tab_fqname;
         return 1;
         exception when others then
                 raise notice ''truncate of % failed - doing 
delete'', v_tab_fqname;


This is against Slony 1.2.10.

Hope this helps,

Jacques.