http://www.slony.info/bugzilla/show_bug.cgi?id=222

--- Comment #1 from Christopher Browne <cbbrowne at ca.afilias.info> 2011-06-20 08:23:10 PDT ---
Step #2 shouldn't be able to be.

If you look at logswitch_finish(), it doesn't request a "bare" truncate of
sl_log_1 or sl_log_2.  When looking at using TRUNCATE (to replace the former
DELETE requests), I was specifically concerned about this sort of case.

It doesn't "bare truncate" - instead, it first attempts to grab an exclusive
lock, with the NOWAIT option.

If there's a competing lock on sl_log_1/sl_log_2, then the attempt to lock will
fail, and you'll get an exception raised such as:

    Slony-I: could not lock sl_log_2 - sl_log_2 not truncated

It only submits a TRUNCATE request if that lock request succeeds, with the
consequence that there's no reason for the transaction to block at the point of
the TRUNCATE request.  At *that* point, it already has an exclusive lock on the
table.

Are you sure this is an issue in 2.0?  It might have been plausible in 1.2.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.