From: Yugo NAGATA <nagata@sraoss.co.jp>
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: coelho@cri.ensmp.fr
Cc: thomas.munro@gmail.com
Cc: m.polyakova@postgrespro.ru
Cc: alvherre@2ndquadrant.com
Cc: pgsql-hackers@postgresql.org
Cc: teodor@sigaev.ru
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
Date: Wed, 7 Jul 2021 22:46:42 +0900
Message-ID: <20210707224642.4e8265865fda4e118c4de5ee@sraoss.co.jp> (raw)
In-Reply-To: <20210707.215016.2091144688016450280.t-ishii@gmail.com>
References: <20210706164624.dd22be9e4f10ed2657d25552@sraoss.co.jp>
<20210707.161123.574070522694073225.t-ishii@gmail.com>
<20210707195323.02f64ddf51c77ce2ca41e465@sraoss.co.jp>
<20210707.215016.2091144688016450280.t-ishii@gmail.com>
On Wed, 07 Jul 2021 21:50:16 +0900 (JST)
Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
> >> Well, "that's very little, let's ignore it" is not technically a right
> >> direction IMO.
> >
> > Hmmm, It seems to me these failures are ignorable because with regard to failures
> > due to -T they occur only the last transaction of each client and do not affect
> > the result such as TPS and latency of successfully processed transactions.
> > (although I am not sure for what sense you use the word "technically"...)
>
> "My application button does not respond once in 100 times. It's just
> 1% error rate. You should ignore it." I would say this attitude is not
> technically correct.
I cannot understand what you want to say. Reporting the number of transactions
that is failed intentionally can be treated as same as he error rate on your
application's button?
> > However, maybe I am missing something. Could you please tell me what do you think
> > the actual harm for users about failures due to -D is?
>
> I don't know why you are referring to -D.
Sorry. It's just a typo as you can imagine.
I am asking you what do you think the actual harm for users due to termination of
retrying by the -T option is.
> >> That's necessarily true in practice. By the time when -T is about to
> >> expire, transactions are all finished in finite time as you can see
> >> the result I showed. So it's reasonable that the very last cycle of
> >> the benchmark will finish in finite time as well.
> >
> > Your script may finish in finite time, but others may not.
>
> That's why I said "practically". In other words "in most cases the
> scenario will finish in finite time".
Sure.
> > Indeed, it is possible an execution of a query takes a long or infinite
> > time. However, its cause would a problematic query in the custom script
> > or other problems occurs on the server side. These are not problem of
> > pgbench and, pgbench itself can't control either. On the other hand, the
> > unlimited number of tries is a behaviours specified by the pgbench option,
> > so I think pgbench itself should internally avoid problems caused from its
> > behaviours. That is, if max-tries=0 could cause infinite or much longer
> > benchmark time more than user expected due to too many retries, I think
> > pgbench should avoid it.
>
> I would say that's user's responsibility to avoid infinite running
> benchmarking. Remember, pgbench is a tool for serious users, not for
> novice users.
Of course, users themselves should be careful of problematic script, but it
would be better that pgbench itself avoids problems if pgbench can beforehand.
> Or, we should terminate the last cycle of benchmark regardless it is
> retrying or not if -T expires. This will make pgbench behaves much
> more consistent.
Hmmm, indeed this might make the behaviour a bit consistent, but I am not
sure such behavioural change benefit users.
Regards,
Yugo Nagata
--
Yugo NAGATA <nagata@sraoss.co.jp>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nagata@sraoss.co.jp, ishii@sraoss.co.jp, coelho@cri.ensmp.fr, thomas.munro@gmail.com, m.polyakova@postgrespro.ru, alvherre@2ndquadrant.com, teodor@sigaev.ru
Subject: Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors
In-Reply-To: <20210707224642.4e8265865fda4e118c4de5ee@sraoss.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox