MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 26 Mar 2018 15:15:38 +0300
From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Teodor Sigaev <teodor@sigaev.ru>, Fabien COELHO <coelho@cri.ensmp.fr>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Organization: Postgres Professional
In-Reply-To: <alpine.DEB.2.20.1803251417220.8109@lancre>
References: <72a0d590d6ba06f242d75c2e641820ec@postgrespro.ru>
 <72ca61a8-b515-1bac-b082-b77952c78b64@sigaev.ru>
 <alpine.DEB.2.20.1803251417220.8109@lancre>
Message-ID: <ae993ae02a7578f70b8012b9f2ca1866@postgrespro.ru>
User-Agent: Roundcube Webmail/1.2.4
Precedence: bulk

On 25-03-2018 15:23, Fabien COELHO wrote:
>> Hm, I took a look on both thread about patch and it seems to me now 
>> it's overcomplicated. With recently committed enhancements of pgbench 
>> (\if, \when) it becomes close to impossible to retry transation in 
>> case of failure. So, initial approach just to rollback such 
>> transaction looks more attractive.
> 
> Yep.

Many thanks to both of you! I'm working on a patch in this direction..

> I think that the best approach for now is simply to reset (command
> zero, random generator) and start over the whole script, without
> attempting to be more intelligent. The limitations should be clearly
> documented (one transaction per script), though. That would be a
> significant enhancement already.

I'm not sure that we can always do this, because we can get new errors 
until we finish the failed transaction block, and we need destroy the 
conditional stack..

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company