Jacques Caron wrote:

>Hi all,
>
>Of course, bug fixes always come in after the release is published :-/
>
>At 20:42 26/01/2006, Chris Browne wrote:
>  
>
>>   2. Improved SUBSCRIBE SET performance. Indices are temporarily
>>   detached during the COPY statements, and then reattached and
>>   reindexed, which, in principle, should mean that subscribing a set
>>   should even be a bit faster than restoring from pg_dump (with
>>   Slony-I all the indices are regenerated together, so there should
>>   be benefits from the data already being in cache).
>>    
>>
>
>[...]
>
>  
>
>>   4. TRUNCATE is used to clear out tables at subscription time, if
>>   possible.
>>    
>>
>
>There is an issue with these two: if TRUNCATE fails (because there's 
>a foreign key referencing that table), then the index creation is not 
>deferred (the exception rolls back any changes in prepareTableForCopy).
>
>Proposed fix (put the truncate-else-delete in a nested BEGIN block):
>
>--- src/backend/slony1_funcs.v80.sql.orig       Fri Jan  6 18:07:46 2006
>+++ src/backend/slony1_funcs.v80.sql    Fri Jan 27 11:32:13 2006
>@@ -47,17 +47,20 @@
>         -- ----
>         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;
>-               execute ''delete from only '' || 
>@NAMESPACE at .slon_quote_input(v_tab_fqname);
>-               return 0;
>+       begin
>+               -- ----
>+               -- 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;
>+                       execute ''delete from only '' || 
>@NAMESPACE at .slon_quote_input(v_tab_fqname);
>+                       return 0;
>+       end;
>  end;
>  ' language plpgsql;
>
>This is against 1.1.5-rc3, but I think it should work against the 
>release as well.
>  
>
That code hadn't changed between RC3 and the release, so yes, that ought
to work.

I don't want to seem overly grumpy about this, but we have been
releasing release candidates since early December.  There was a month
and a half of release candidates; was there some special reason not to
have mentioned this *before* we released 1.1.5?

I'm much much grumpier about the paucity of test reports; despite
repeated solicitations, apparently nobody much cares about whether
Slony-I can be claimed to be supportable on Solaris.  Virtually all of
the test reports were from people internal to Afilias, and there are
plenty of platforms that we conspicuously *don't* care about, and won't
be testing.

>Also TRUNCATE is only used for PostgreSQL 8.0+, apparently.
>  
>
Yes, it's only as of 8.x that we have subtransactions so that we can
*attempt* the truncate and actually have a recovery if that fails.

>I have another issue at the moment with a supposedly duplicate key in 
>the updates just after the copy_set is done, I'll post when I have 
>more info (and hopefully a fix).
>
>  
>
Fixes are good...  Repeatable test cases are also very good...