On Wed, 26 Sep 2007, Christopher Browne wrote:

> Jeff Frost <jeff at frostconsultingllc.com> writes:
>> For extra background on this bug, see the thread here:
>> http://lists.slony.info/pipermail/slony1-general/2007-September/006687.html
>>
>> This is on Slony1-1.2.10, PostgreSQL-8.1.9:
>>
>> I've run into a situation on a client cluster composed of a master and
>> 2 slave nodes where a deadlock on one of the slaves happens quite
>> regularly during any EXECUTE SCRIT commands.  It seems if slony loses
>> the deadlock, some of the tables are left in a not altered for
>> replication state and this breaks replication.
>
> I'm going to set up (heh) a test case, let's call it
> "testdeadlockddl", which will try to "tickle" this problem.
>
> The approach:
>
> - I'll start by creating a set that is replicated, and where some data
>  is flowing thru.
>
> - I'll set up some queries against the replica in order to try to
>  encourage deadlocks.
>
> - Then an "EXECUTE SCRIPT" will try adding a new table.  As a side effect,
>  it will implicitly require locks on all the replicated tables.
>
> I don't see that there are other particular details to this, right?

You seem to be right on the money with my experience, Christopher.  Perhaps if 
your slave is inside a VM making it a little less performant would be more 
likley to cause the deadlock and show the problem?  I mention this because our 
slave is not as performant as the master and so it deadlocks more often during 
execute scripts than the master did when the master shoulders the entire load.

-- 
Jeff Frost, Owner 	<jeff at frostconsultingllc.com>
Frost Consulting, LLC 	http://www.frostconsultingllc.com/
Phone: 650-780-7908	FAX: 650-649-1954