From: | Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
Subject: | Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error |
Date: | 2022-09-03 05:36:37 |
Message-ID: | CALtqXTdMH+ufW+FTjQnw3sYFMaFH=tTuEaV3YjsveR_VuZV6zA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 28, 2022 at 8:35 AM Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> wrote:
> On Fri, 25 Mar 2022 16:19:54 -0400
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> > >> [...] 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.
> >
> > > 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 am not convinced this is a great idea. The current behavior is that
> > a statement is not prepared until it's about to be executed, and I think
> > we chose that deliberately to avoid semantic differences between prepared
> > and not-prepared mode. For example, if a script looks like
> >
> > CREATE FUNCTION foo(...) ...;
> > SELECT foo(...);
> > DROP FUNCTION foo;
> >
> > trying to prepare the SELECT in advance would lead to failure.
> >
> > We could perhaps get away with preparing the commands within a pipeline
> > just before we start to execute the pipeline, but it looks to me like
> > this patch tries to prepare the entire script in advance.
> >
> Well, the semantic differences is already in the current behavior.
> Currently, pgbench fails to execute the above script in prepared mode
> because it prepares the entire script in advance just before the first
> command execution. This patch does not change the semantic.
>
> > BTW, the cfbot says the patch is failing to apply anyway ...
> > I think it was sideswiped by 4a39f87ac.
>
> I attached the rebased patch.
>
> Regards,
> Yugo Nagata
>
> --
> Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
>
Hi Kyotaro Horiguchi, Fabien Coelho, Daniel Gustafsson,
Since you haven't had time to write a review the last many days, the author
replied
with a rebased patch for a long time and never heard. We've taken your name
off the reviewer list for this patch. Of course, you are still welcome to
review it if you can
find the time. We're removing your name so that other reviewers know the
patch still needs
attention. We understand that day jobs and other things get in the way of
doing patch
reviews when you want to, so please come back and review a patch or two
later when you
have more time.
--
Ibrar Ahmed
From | Date | Subject | |
---|---|---|---|
Next Message | Ibrar Ahmed | 2022-09-03 05:47:32 | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |
Previous Message | Pavel Stehule | 2022-09-03 05:30:03 | warning: comparison of integer expressions of different signedness related to simd.h |