Update of /home/cvsd/slony1/slony1-engine/src/backend
In directory main.slony.info:/tmp/cvs-serv32546

Modified Files:
      Tag: REL_2_0_STABLE
	slony1_funcs.sql 
Log Message:
Aleksander Kmetec submitted this patch which addresses a race condition
potentially effecting long time locking or data loss on TRUNCATE.

Dataloss bug, described here:
http://lists.slony.info/pipermail/slony1-general/2009-July/009663.html

Statement blocking bug, described here:
http://lists.slony.info/pipermail/slony1-general/2009-July/009664.html

Patch is to preface TRUNCATE logic with an attempt (in an exception
block) to acquire an exclusive lock on the apropos sl_log_* table.
The NOWAIT option raises a (caught!) exception if there are any other
processes holding onto the table.


Index: slony1_funcs.sql
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/src/backend/slony1_funcs.sql,v
retrieving revision 1.145.2.13
retrieving revision 1.145.2.14
diff -C2 -d -r1.145.2.13 -r1.145.2.14
*** slony1_funcs.sql	21 Jul 2009 21:15:51 -0000	1.145.2.13
--- slony1_funcs.sql	28 Jul 2009 16:03:49 -0000	1.145.2.14
***************
*** 5236,5239 ****
--- 5236,5255 ----
  	if v_current_status = 2 then
  		v_purgeable := 'true';
+ 		
+ 		-- ----
+ 		-- Attempt to lock sl_log_2 in order to make sure there are no other transactions 
+ 		-- currently writing to it. Exit if it is still in use. This prevents TRUNCATE from 
+ 		-- blocking writers to sl_log_2 while it is waiting for a lock. It also prevents it 
+ 		-- immediately truncating log data generated inside the transaction which was active 
+ 		-- when logswitch_finish() was called (and was blocking TRUNCATE) as soon as that 
+ 		-- transaction is committed.
+ 		-- ----
+ 		begin
+ 			lock table @NAMESPACE at .sl_log_2 in exclusive mode nowait;
+ 		exception when lock_not_available then
+ 			raise notice 'Slony-I: could not lock sl_log_2 - sl_log_2 not truncated';
+ 			return -1;
+ 		end;
+ 
  		-- ----
  		-- The cleanup thread calls us after it did the delete and
***************
*** 5241,5245 ****
  		-- can truncate it and the log switch is done.
  		-- ----
- 		
  	        for v_origin, v_seqno, v_xmin in
  		  select ev_origin, ev_seqno, "pg_catalog".txid_snapshot_xmin(ev_snapshot) from @NAMESPACE at .sl_event
--- 5257,5260 ----
***************
*** 5275,5278 ****
--- 5290,5309 ----
  	if v_current_status = 3 then
  		v_purgeable := 'true';
+ 
+ 		-- ----
+ 		-- Attempt to lock sl_log_1 in order to make sure there are no other transactions 
+ 		-- currently writing to it. Exit if it is still in use. This prevents TRUNCATE from 
+ 		-- blocking writes to sl_log_1 while it is waiting for a lock. It also prevents it 
+ 		-- immediately truncating log data generated inside the transaction which was active 
+ 		-- when logswitch_finish() was called (and was blocking TRUNCATE) as soon as that 
+ 		-- transaction is committed.
+ 		-- ----
+ 		begin
+ 			lock table @NAMESPACE at .sl_log_1 in exclusive mode nowait;
+ 		exception when lock_not_available then
+ 			raise notice 'Slony-I: could not lock sl_log_1 - sl_log_1 not truncated';
+ 			return -1;
+ 		end;
+ 
  		-- ----
  		-- The cleanup thread calls us after it did the delete and