[Bucardo-general] KID dies with 'could not serialize access due to concurrent update' (prevents replication)

Greg Sabino Mullane greg at endpoint.com
Fri Dec 9 04:15:29 UTC 2011


On Wed, Dec 07, 2011 at 02:06:11AM -0500, Bill McGonigle wrote:
...
> None of our code is setting transactions to SERIALIZABLE, and I've seen such 
> warnings before in the bucardo log (which seem to have been transient - I 
> see the code just sleeps and tries again).  But in this case, it's halting 
> the works, and my "KID Total delta count" is only growing.  Is this bucardo 
> stepping on itself?  If so, is there a way to get it to be less parallel 
> so that it can finish one transaction?

That's a fairly common warning on busy systems, and there is little that 
can be easily done to solve it. The larger the number of deltas, the 
longer a Bucardo sync transaction will take, and the greater the chance 
of a serialization error. Bucardo needs to be in serialiable mode to 
ensure a consistent snapshot during all of its querying/deleting/inserting.

It is not Bucardo interfering with itself (unless you have the same table 
involved in different active syncs.) It is also unrelated to uptime.

You came across one way to solve this: block other processes that are 
updating the tables in question at the same time. There is a brute force 
way to try and get around this problem via Bucardo itself. If you create 
a file named /tmp/bucardo-force-lock-foobar, where foobar is the name 
of your sync, Bucardo will attempt to lock all the tables involved in 
the sync at the start of the transaction. This will solve most serialization 
errors (at the obvious high cost of locking out other processes!). The 
default lock level is EXCLUSIVE. You can change this by putting the desired 
lock level inside the file (its existence is enough to trigger the locking, 
of course, so the lock mode inside of it is optional).

Another "solution" is to use Postgres 9.1, which has a greatly improved 
serialization mode which may prevent some serialization errors from 
occurring in the first place.

I would be remiss is stating that yet another solution is Bucardo 5, which 
does things a lot more efficiently than Bucardo 5, which means greatly 
reduced transaction times, which means less chance for serialization 
errors.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
Url : https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20111208/2af31a03/attachment.bin 


More information about the Bucardo-general mailing list