On 2/13/2008 10:40 AM, Dawid Kuroczko wrote:
> On Feb 13, 2008 4:07 PM, Andrew Sullivan <ajs at crankycanuck.ca> wrote:
>> On Wed, Feb 13, 2008 at 12:52:49AM +0100, Dawid Kuroczko wrote:
>>
>> > For slony-I enabled database you will always get many rollbacks
>> > a minute.
>>
>> > In short: slony's commiting instead of rolling back helps database
>> > monitoring.
>>
>> If you don't collect baselines of your application for what is its normal
>> behaviour, I suggest your monitoring plan needs rework.  You still ought to
>> be able to see unusual numbers of rollbacks with the tool you want.  It just
>> isn't "0".  But your baseline is whatever it is, and if your monitor tool
>> can't compare the current behavior to some arbitrary baseline, your tool
>> needs work.
> 
> Of course my tool has a baseline.  The slaves have constant rate between
> 39 to 41 rollbacks per minute.  The master calls issues ROLLBACK
> between 45 and 60, with average of 50 per minute.  Alarm levels are set
> accordingly.
> 
> Now, the number of rollbacks on master is closely related to number of
> DMLs issued (45-50 : quiet database) (60 -- DML load).
> 
> But still I feel this is more like a workaround, especially that since 8.3.x
> there should be no difference between commit and rollback for read-only
> queries.  Or am I wrong?

Which means that this might be an option for Slony-I version 2.0. I will 
look over it.


Jan

-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin