Re: pgbench and timestamps

Thanks for your analysis.

Regards

El mié., 24 jun. 2020 a las 17:17, Tom Lane (<tgl(at)sss(dot)pgh(dot)pa(dot)us>) escribió:

> I wrote:
> > David Rowley <dgrowleyml(at)gmail(dot)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
>