Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, alvherre(at)alvh(dot)no-ip(dot)org, nagata(at)sraoss(dot)co(dot)jp, thomas(dot)munro(at)gmail(dot)com, m(dot)polyakova(at)postgrespro(dot)ru, pgsql-hackers(at)postgresql(dot)org, teodor(at)sigaev(dot)ru
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Date: 2022-04-10 07:37:15
Message-ID: alpine.DEB.2.22.394.2204100928170.232675@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2022-04-10 10:43:48 Re: Defer selection of asynchronous subplans until the executor initialization stage
Previous Message Tom Lane 2022-04-10 03:47:20 Re: Can 64bit libpq to access 32bit postgresDB in X86_64 platform