Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M329847=pgsql-hackers-arkari@postgresql.org>)
	id 1dLoSZ-00084Y-Sx
	for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Jun 2017 10:26:36 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M329847=pgsql-hackers-arkari@postgresql.org>)
	id 1dLoSZ-0006YS-Fw
	for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Jun 2017 10:26:35 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <m.polyakova@postgrespro.ru>)
	id 1dLoSX-0006MM-79
	for pgsql-hackers@postgresql.org; Fri, 16 Jun 2017 10:26:33 +0000
Received: from mail.postgrespro.ru ([93.174.131.138])
	by makus.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from <m.polyakova@postgrespro.ru>)
	id 1dLoST-0006ci-Sl
	for pgsql-hackers@postgresql.org; Fri, 16 Jun 2017 10:26:32 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.postgrespro.ru (Postfix) with ESMTP id 4497E21C1AEE;
	Fri, 16 Jun 2017 13:26:28 +0300 (MSK)
X-Virus-Scanned: Debian amavisd-new at postgrespro.ru
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru;
	s=mail; t=1497608788;
	bh=F3Riklkul8cu8VzgEcL2o+TnfVXnT4EdNSzGXOJhCEM=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References;
	b=I1MdX0uJwslbnvW/Ad89mxUDJLHX7gu8PUns1Z9kI2fOB/TNJGsdRJhARZMvzTtaG
	 t5uuDfrxNWS1UEar3ftMkiy/ASULxFEsbAHUbGYfMCrRNqKp1SKMhORrmCC8TLSsCX
	 ex0Uc6oHYdirUb8RHWOaQg6qyC74FM/NAgX1QgyQ=
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 16 Jun 2017 13:26:28 +0300
From: Marina Polyakova <m.polyakova@postgrespro.ru>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>,
 Kevin Grittner <kgrittn@gmail.com>, Thomas Munro
 <thomas.munro@enterprisedb.com>
Subject: Re: WIP Patch: Pgbench Serialization and deadlock errors
Organization: Postgres Professional
In-Reply-To: <20170615191636.mqzk7ongddmhoqzm@alap3.anarazel.de>
References: <72a0d590d6ba06f242d75c2e641820ec@postgrespro.ru>
 <20170615191636.mqzk7ongddmhoqzm@alap3.anarazel.de>
Message-ID: <d979e8d9a3bb31fff69c31745b95ae78@postgrespro.ru>
X-Sender: m.polyakova@postgrespro.ru
User-Agent: Roundcube Webmail/1.2.4
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

> Hi,

Hello!

> I think that's a good idea and sorely needed.

Thanks, I'm very glad to hear it!

>> - if there were these failures during script execution this 
>> "transaction" is
>> marked
>> appropriately in logs;
>> - numbers of "transactions" with these failures are printed in 
>> progress, in
>> aggregation logs and in the end with other results (all and for each
>> script);
> 
> I guess that'll include a "rolled-back %' or 'retried %' somewhere?

Not exactly, see documentation:

+   If transaction has serialization / deadlock failure or them both 
(last thing
+   is possible if used script contains several transactions; see
+   <xref linkend="transactions-and-scripts"
+   endterm="transactions-and-scripts-title"> for more information), its
+   <replaceable>time</> will be reported as <literal>serialization 
failure</> /
+   <literal>deadlock failure</> /
+   <literal>serialization and deadlock failures</> appropriately.

+   Example with serialization, deadlock and both these failures:
+<screen>
+1 128 24968 0 1496759158 426984
+0 129 serialization failure 0 1496759158 427023
+3 129 serialization failure 0 1496759158 432662
+2 128 serialization failure 0 1496759158 432765
+0 130 deadlock failure 0 1496759159 460070
+1 129 serialization failure 0 1496759160 485188
+2 129 serialization and deadlock failures 0 1496759160 485339
+4 130 serialization failure 0 1496759160 485465
+</screen>

I have understood proposals in next messages of this thread that the 
most interesting case is to retry failed transaction. Do you think it's 
better to write for example "rolled-back after % retries (serialization 
failure)' or "time (retried % times, serialization and deadlock 
failures)'?

>> Advanced options:
>> - mostly for testing built-in scripts: you can set the default 
>> transaction
>> isolation level by the appropriate benchmarking option (-I);
> 
> I'm less convinced of the need of htat, you can already set arbitrary
> connection options with
> PGOPTIONS='-c default_transaction_isolation=serializable' pgbench

Oh, thanks, I forgot about it =[

>> P.S. Does this use case (do not retry transaction with serialization 
>> or
>> deadlock failure) is most interesting or failed transactions should be
>> retried (and how much times if there seems to be no hope of 
>> success...)?

> I can't quite parse that sentence, could you restate?

Álvaro Herrera later in this thread has understood my text right:

> As far as I understand her proposal, it is exactly the opposite -- if a
> transaction fails, it is discarded.  And this P.S. note is asking
> whether this is a good idea, or would we prefer that failing
> transactions are retried.

With his explanation has my text become clearer?

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers