Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Yugo NAGATA <nagata@sraoss.co.jp>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Fabien COELHO <coelho@cri.ensmp.fr>, pgsql-hackers@postgresql.org
Date: 2023-02-08T12:09:28Z
Lists: pgsql-hackers
On 2022-Sep-30, Yugo NAGATA wrote: > Well, I still don't understand why we need to prepare only "the > commands within a pipeline" before starting pipeline. In the current > behavior, the entire script is prepared in advance just before executing > the first SQL command in the script, instead of preparing each command > one by one. This patch also prepare the entire script in advance, so > there is no behavioural change in this sense. > > However, there are a few behavioural changes. One is that the preparation > is not counted in the command performance statistics as Fabien mentioned. > Another is that all meta-commands including \shell and \sleep etc. are > executed before the preparation. > > To reduce impact of these changes, I updated the patch to prepare the > commands just before executing the first SQL command or \startpipeline > meta-command instead of at the beginning of the script. I propose instead the following: each command is prepared just before it's executed, as previously, and if we see a \startpipeline, then we prepare all commands starting with the one just after, and until the \endpipeline. I didn't test additional cases other than the one you submitted. Testing this I noticed that pg_log_debug et al don't support multithreading very well -- the lines are interspersed. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Commits
-
Fix pgbench in prepared mode with an empty pipeline
- 8f5e42d33469 16.0 landed
- 34f51196573c 15.4 landed
-
pgbench: Prepare commands in pipelines in advance
- 663e50e83211 14.8 landed
- 108a22bd14d4 15.3 landed
- 038f586d5f1d 16.0 landed
-
Add -M (query mode) option per ITAGAKI Takahiro
- 49639a7b2c52 8.4.0 cited