Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error

From: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
To: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
Cc: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error
Date: 2021-07-21 01:49:09
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Mon, 19 Jul 2021 10:51:36 +0900
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote:

> Hello Fabien,
> On Sat, 17 Jul 2021 07:03:01 +0200 (CEST)
> Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> >
> > Hello Yugo-san,
> >
> > > [...] One way to avoid these errors is to send Parse messages before
> > > pipeline mode starts. I attached a patch to fix to prepare commands at
> > > starting of a script instead of at the first execution of the command.
> >
> > > What do you think?
> >
> > ISTM that moving prepare out of command execution is a good idea, so I'm
> > in favor of this approach: the code is simpler and cleaner.
> >
> > ISTM that a minor impact is that the preparation is not counted in the
> > command performance statistics. I do not think that it is a problem, even
> > if it would change detailed results under -C -r -M prepared.
> I agree with you. Currently, whether prepares are sent in pipeline mode or
> not depends on whether the first SQL command is placed between \startpipeline
> and \endpipeline regardless whether other commands are executed in pipeline
> or not. ISTM, this behavior would be not intuitive for users. Therefore,
> I think preparing all statements not using pipeline mode is not problem for now.
> If some users would like to send prepares in pipeline, I think it would be
> better to provide more simple and direct way. For example, we prepare statements
> in pipeline if the user use an option, or if the script has at least one
> \startpipeline in their pipeline. Maybe, --pipeline option is useful for users
> who want to use pipeline mode for all queries in scirpts including built-in ones.
> However, these features seems to be out of the patch proposed in this thread.
> > Patch applies & compiles cleanly, global & local make check ok. However
> > the issue is not tested. I think that the patch should add a tap test case
> > for the problem being addressed.
> Ok. I'll add a tap test to confirm the error I found is avoidable.
> > I'd suggest to move the statement preparation call in the
> I thought so at first, but I noticed we cannot do it at least if we are
> using -C because the connection may not be established in the
> > In comments: not yet -> needed.
> Thanks. I'll fix it.

I attached the updated patch v2, which includes a comment fix and a TAP test.

Yugo Nagata

Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
v2-pgbench-prepare.patch text/x-diff 3.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message 2021-07-21 02:15:14 add 'noError' to euc_tw_and_big5.c
Previous Message James Coleman 2021-07-21 01:39:14 Re: [PATCH] Use optimized single-datum tuplesort in ExecSort