Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1ndS9Q-0001Ib-H4
	for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Apr 2022 07:38:24 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1ndS8P-0003Gs-Oo
	for pgsql-hackers@arkaria.postgresql.org; Sun, 10 Apr 2022 07:37:21 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <coelho@cri.ensmp.fr>)
	id 1ndS8P-0003Gj-Fw
	for pgsql-hackers@lists.postgresql.org; Sun, 10 Apr 2022 07:37:21 +0000
Received: from sfr-1.cri.mines-paristech.fr ([77.158.180.225]
 helo=smtp.cri.ensmp.fr)
	by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <coelho@cri.ensmp.fr>)
	id 1ndS8L-0003u0-Ld
	for pgsql-hackers@postgresql.org; Sun, 10 Apr 2022 07:37:20 +0000
Received: from pseudo (185.141.6.84.rev.sfr.net [84.6.141.185])
	by smtp.cri.ensmp.fr (Postfix) with ESMTPSA id 6F0A3C0228;
	Sun, 10 Apr 2022 09:40:43 +0200 (CEST)
Date: Sun, 10 Apr 2022 09:37:15 +0200 (CEST)
From: Fabien COELHO <coelho@cri.ensmp.fr>
X-X-Sender: fabien@pseudo
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Tatsuo Ishii <ishii@sraoss.co.jp>, alvherre@alvh.no-ip.org,
    nagata@sraoss.co.jp, thomas.munro@gmail.com, m.polyakova@postgrespro.ru,
    pgsql-hackers@postgresql.org, teodor@sigaev.ru
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock
 errors
In-Reply-To: <4183048.1649536705@sss.pgh.pa.us>
Message-ID: <alpine.DEB.2.22.394.2204100928170.232675@pseudo>
References: <20220404.101431.333095021655639605.t-ishii@sranhm.sra.co.jp>
 <alpine.DEB.2.22.394.2204041518020.3174331@pseudo>
 <20220405.083805.1138012899895218258.t-ishii@sranhm.sra.co.jp>
 <20220406.100005.1796406557268900302.t-ishii@sranhm.sra.co.jp>
 <4183048.1649536705@sss.pgh.pa.us>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="2056645051-576460578-1649576236=:232675"
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/alpine.DEB.2.22.394.2204100928170.232675%40pseudo>
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--2056645051-576460578-1649576236=:232675
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT


Hello Tom,

> The buildfarm is still complaining about the synopsis being too
> wide for PDF format.  I think what we ought to do is give up on
> using a <synopsis> for log lines at all, and instead convert the
> documentation into a tabular list of fields.  Proposal attached,
> which also fixes a couple of outright errors.

Looks ok. Html doc generation ok.

While looking at the html outpout, the "pgbench" command line just below 
wraps strangely:

   pgbench --aggregate-interval=10 --time=20 --client=10 --log --rate=1000
   --latency-limit=10 --failures-detailed --max-tries=10 test

ISTM that there should be no nl in the <textinput>pgbench …</textinput> 
section, although maybe it would trigger a complaint in the pdf format.

> One thing that this doesn't fix is that the existing text appears
> to suggest that the "failures" column is something different from
> the sum of the serialization_failures and deadlock_failures
> columns, which it's obvious from the code is not so.  If this isn't
> a code bug then I think we ought to just drop that column entirely,
> because it's redundant.

Ok. Fine with me. Possibly at some point there was the idea that there 
could be other failures counted, but there are none. Also, there has been 
questions about the failures detailed option, or whether the reports 
should always be detailed, and the result may be some kind of not 
convincing compromise.

> (BTW, now that I've read this stuff I am quite horrified by how
> the non-aggregated log format has been mangled for error retries,
> and will be probably be submitting a proposal to change that.
> But that's a different issue.)

Indeed, any improvement is welcome!

-- 
Fabien.
--2056645051-576460578-1649576236=:232675--