I see a place where the new "log switch/truncate" logic is vulnerable
to locking, which could doubtless cause some problems...

	-- ----
	-- status = 2: sl_log_1 active, cleanup sl_log_2
	-- ----
	if v_current_status = 2 then
		-- ----
		-- The cleanup thread calls us after it did the delete and
		-- vacuum of both log tables. If sl_log_2 is empty now, we
		-- can truncate it and the log switch is done.
		-- ----
		for v_dummy in select 1 from @NAMESPACE at .sl_log_2 loop
			-- ----
			-- Found a row ... log switch is still in progress.
			-- ----
			raise notice ''Slony-I: log switch to sl_log_1 still in progress - sl_log_2 not truncated'';
			return -1;
		end loop;

		raise notice ''Slony-I: log switch to sl_log_1 complete - truncate sl_log_2'';
		truncate @NAMESPACE at .sl_log_2;
		perform "pg_catalog".setval(''@NAMESPACE at .sl_log_status'', 0);
		return 1;
	end if;

Suppose someone's running either:
 a) VACUUM on the whole database, or
 b) pg_dump of a whole database

Those are conditions that could lead to the TRUNCATE sitting blocked
for a potentially indeterminate period of time, which strikes me as
risky...

I would be *way* more comfortable adding in a check to see if there
are any O/S locks on sl_log_2...

Thus, we might add...

for v_dummy in select pid from pg_catalog.pg_locks l, pg_catalog.pg_class c, pg_catalog.pg_namespace n 
   where c.oid = l.relation and 
         c.name = 'sl_log_2' and
         n.nspname = '@NAMESPACE@' and
         c.relnamespace = n.oid and
         l.pid <> pg_backend_pid() loop
    raise notice ''Slony-I: process % has lock on sl_log_2 - sl_log_2 not truncated'';
    return -1;
end loop;

And the equivalent for sl_log_1.

This is still probably *somewhat* susceptible to race conditions, but
it seems to be a "safening action" to me...
-- 
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)