Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Date
Msg-id alpine.DEB.2.22.394.2204100928170.232675@pseudo
Whole thread Raw
In response to Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors  (Tatsuo Ishii <ishii@sraoss.co.jp>)
List pgsql-hackers
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.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Can 64bit libpq to access 32bit postgresDB in X86_64 platform
Next
From: Etsuro Fujita
Date:
Subject: Re: Defer selection of asynchronous subplans until the executor initialization stage