Re: pgbench and timestamps - Mailing list pgsql-general

From Tom Lane
Subject Re: pgbench and timestamps
Date
Msg-id 2206076.1593011840@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgbench and timestamps  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgbench and timestamps  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: pgbench and timestamps  (Jaime Soler <jaime.soler@gmail.com>)
List pgsql-general
I wrote:
> David Rowley <dgrowleyml@gmail.com> writes:
>> I don't often do much with pgbench and variables, but there are a few
>> things that surprise me here.
>> 1) That pgbench replaces variables within single quotes, and;
>> 2) that we still think it's a variable name when it starts with a digit, and;
>> 3) We replace variables that are undefined.

> Also (4) this only happens when in non-simple query mode --- the
> example works fine without "-M prepared".

After looking around in the code, it seems like the core of the issue
is that pgbench.c's parseQuery() doesn't check whether a possible
variable name is actually defined, unlike assignVariables() which is
what does the same job in simple query mode.  So that explains the
behavioral difference.

The reason for doing that probably was that parseQuery() is run when
the input file is read, so that relevant variables might not be set
yet.  We could fix that by postponing the work to be done at first
execution of the query, as is already the case for PQprepare'ing the
query.

Also, after further thought I realize that (1) absolutely is a bug
in the non-simple query modes, whatever you think about it in simple
mode.  The non-simple modes are trying to pass the variable values
as extended-query-protocol parameters, and the backend is not going
to recognize $n inside a literal as being a parameter.

If we fixed (1) and (3) I think there wouldn't be any great need
to tighten up (2).

            regards, tom lane



pgsql-general by date:

Previous
From: "Jim Hurne"
Date:
Subject: RE: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked
Next
From: Thomas Boussekey
Date:
Subject: Re: autovacuum failing on pg_largeobject and disk usage of thepg_largeobject growing unchecked