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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error
Date: 2022-03-25 20:19:54
Message-ID: 3461267.1648239594@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

BTW, the cfbot says the patch is failing to apply anyway ...
I think it was sideswiped by 4a39f87ac.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2022-03-25 20:30:05 Re: SQL/JSON: JSON_TABLE
Previous Message Tomas Vondra 2022-03-25 20:10:41 Re: logical decoding and replication of sequences