Re: pgsql: Emit parameter values during query bind/execute errors
От | Alvaro Herrera |
---|---|
Тема | Re: pgsql: Emit parameter values during query bind/execute errors |
Дата | |
Msg-id | 20191230154837.GA13289@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: pgsql: Emit parameter values during query bind/execute errors (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: