Thread: pgsql: Emit parameter values during query bind/execute errors
Emit parameter values during query bind/execute errors This makes such log entries more useful, since the cause of the error can be dependent on the parameter values. Author: Alexey Bashtanov, Álvaro Herrera Discussion: https://postgr.es/m/0146a67b-a22a-0519-9082-bc29756b93a2@imap.cc Reviewed-by: Peter Eisentraut, Andres Freund, Tom Lane Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/ba79cb5dc841104cf4810b5c23af4f881079dbb5 Modified Files -------------- doc/src/sgml/config.sgml | 23 +++++ src/backend/nodes/params.c | 110 ++++++++++++++++++++++++ src/backend/tcop/postgres.c | 119 ++++++++++++++++---------- src/backend/utils/misc/guc.c | 10 +++ src/backend/utils/misc/postgresql.conf.sample | 1 + src/bin/pgbench/t/001_pgbench_with_server.pl | 44 ++++++++++ src/include/nodes/params.h | 10 +++ src/include/utils/guc.h | 1 + 8 files changed, 271 insertions(+), 47 deletions(-)
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Emit parameter values during query bind/execute errors
(Some of?) the Windows buildfarm critters don't like the test
case you added. I speculate that the test pattern is neglecting
to allow for Windows-style newlines.
regards, tom lane
On 2019-Dec-12, Tom Lane wrote: > Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > > Emit parameter values during query bind/execute errors > > (Some of?) the Windows buildfarm critters don't like the test > case you added. I speculate that the test pattern is neglecting > to allow for Windows-style newlines. Hmm, the affected ones (jacana and fairywren only AFAICS) seem to be gcc-based, which presumably work differently than the msvc-based in how newlines are interpreted in the test script. I pushed an attempted blind fix. I *hope* that those two are not the only Windows ones running the pgbench tap test! -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Hmm, the affected ones (jacana and fairywren only AFAICS) seem to be
> gcc-based, which presumably work differently than the msvc-based in how
> newlines are interpreted in the test script. I pushed an attempted
> blind fix.
> I *hope* that those two are not the only Windows ones running the
> pgbench tap test!
[ scrapes buildfarm results... ] The Windows critters that are
running that test seem to be
name | operating_system | compiler
-----------+------------------+---------------
bowerbird | Windows | Visual Studio
drongo | Windows | Visual Studio
fairywren | Windows / Msys | gcc
jacana | Windows | gcc
So yeah, the MSVC ones were happy with the test as you had it.
Interesting ... it's not obvious why that would have anything
to do with the behavior of a Perl regexp. Maybe they are using
a different Perl version?
regards, tom lane
On 2019-Dec-12, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Hmm, the affected ones (jacana and fairywren only AFAICS) seem to be
> > gcc-based, which presumably work differently than the msvc-based in how
> > newlines are interpreted in the test script. I pushed an attempted
> > blind fix.
>
> > I *hope* that those two are not the only Windows ones running the
> > pgbench tap test!
>
> [ scrapes buildfarm results... ] The Windows critters that are
> running that test seem to be
>
> name | operating_system | compiler
> -----------+------------------+---------------
> bowerbird | Windows | Visual Studio
> drongo | Windows | Visual Studio
> fairywren | Windows / Msys | gcc
> jacana | Windows | gcc
>
> So yeah, the MSVC ones were happy with the test as you had it.
> Interesting ... it's not obvious why that would have anything
> to do with the behavior of a Perl regexp. Maybe they are using
> a different Perl version?
Jacana seems to be using 5.8.8 according to $Config{version} (though
5.26 is in PATH, strangely); fairywren is 5.30.
Bowerbird is 5.16.2 and Drongo 5.24.3.
I don't think the buildfarm tells us about Perl internals to know if
they interpret platform-dependent newlines differently.
I suppose the difference might be the way Perl interprets the literal
newline embedded in the regexp, versus how the log file is written.
With the [\r\n]+ pattern the platform schizophreny no longer matters.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Dec 31, 2019 at 2:18 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2019-Dec-12, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Hmm, the affected ones (jacana and fairywren only AFAICS) seem to be
> > gcc-based, which presumably work differently than the msvc-based in how
> > newlines are interpreted in the test script. I pushed an attempted
> > blind fix.
>
> > I *hope* that those two are not the only Windows ones running the
> > pgbench tap test!
>
> [ scrapes buildfarm results... ] The Windows critters that are
> running that test seem to be
>
> name | operating_system | compiler
> -----------+------------------+---------------
> bowerbird | Windows | Visual Studio
> drongo | Windows | Visual Studio
> fairywren | Windows / Msys | gcc
> jacana | Windows | gcc
>
> So yeah, the MSVC ones were happy with the test as you had it.
> Interesting ... it's not obvious why that would have anything
> to do with the behavior of a Perl regexp. Maybe they are using
> a different Perl version?
Jacana seems to be using 5.8.8 according to $Config{version} (though
5.26 is in PATH, strangely); fairywren is 5.30.
Bowerbird is 5.16.2 and Drongo 5.24.3.
The perl used to run prove is not the same on Msys as the perl we build against. The former needs to be targeted at Msys, so it's the one that Msys provides, but the latter needs to be pure Windows native, so we use StrawberryPerl or ActivePerl.
So for fairywren we use 5.30.0 / 5.24.3 while on jacana we use 5.8.8 / 5.26.3. The former can be seen in the config bf_perl_version, while the latter can be seen in the configure output.
For MSVC we use the same perl for both purposes.
I don't think the buildfarm tells us about Perl internals to know if
they interpret platform-dependent newlines differently.
I suppose the difference might be the way Perl interprets the literal
newline embedded in the regexp, versus how the log file is written.
With the [\r\n]+ pattern the platform schizophreny no longer matters.
In general I don't think putting embedded newline literals inside a regex is great practice. It's too easy to miss other trailing whitespace characters. so I think the fix is an improvement anyway.
I normally spell this as \r?\n but as you say TIMTOWTDI.
cheers
andrew