Re: pgbench vs. SERIALIZABLE - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench vs. SERIALIZABLE
Date
Msg-id alpine.DEB.2.02.1305190737170.7438@localhost6.localdomain6
Whole thread Raw
In response to Re: pgbench vs. SERIALIZABLE  (Marko Tiikkaja <marko@joh.to>)
List pgsql-hackers
>> Should it give up trying under some conditions, say there are more errors
>> than transactions?
>
> I don't really see the point of that.  I can't think of a scenario where you 
> would get too many serialization errors to even finish the pgbench test.

My point is really to avoid in principle a potential infinite loop under 
option -t in these conditions, if all transactions are failing because of 
a table lock for instance. If pgbench is just killed, I'm not sure you get 
a report.

> At any rate, as proposed, this would fail horribly if the very first 
> transaction fails, or the second transaction fails twice, etc..

Yep. Or maybe some more options to control the expected behavior on 
transaction failures ? --stop-client-on-fail (current behavior), 
--keep-trying-indefinitely, --stop-client-after=<nfails>... or nothing if 
this is not a problem:-)

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Better LWLocks with compare-and-swap (9.4)
Next
From: Greg Smith
Date:
Subject: Block write statistics WIP