Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ilxHl-0003tN-2K for pgsql-committers@arkaria.postgresql.org; Mon, 30 Dec 2019 15:48:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ilxHi-0007EF-ML for pgsql-committers@arkaria.postgresql.org; Mon, 30 Dec 2019 15:48:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ilxHi-0007E8-7g for pgsql-committers@lists.postgresql.org; Mon, 30 Dec 2019 15:48:46 +0000 Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ilxHe-0003g0-6s for pgsql-committers@lists.postgresql.org; Mon, 30 Dec 2019 15:48:44 +0000 Received: by mail-pl1-x643.google.com with SMTP id f20so14786063plj.5 for ; Mon, 30 Dec 2019 07:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=7ZHVlh4qk+ldd/FOuzL6cOXR2oVWNlIf7rlUpEiwMBY=; b=WA/dl/a20wZU/wmP0tHffvXVwoq8it3QjbEAdO42UZ/rgjn7vZ1Z6+Z4Wocboz+w4Y f9N/u3IW82M9jEdHU1EtAqs7xF+8ehfZXSZxba744W5a+4yXUQKTiPSRY30q5UyFEAb+ xIvV5Q+Wssisrh5lJu0oZg9m7e8czyZQhQHbGj2ioNo/3n8B3/40xyKyENwdMng7klQ6 l0ntAFW1veEZN9XsjJONuTrHFPYwP7a3SRyAPXYhLp0bX2HquqUwHWL8RUER/0YmMlYZ dwkYDmOZFXzPwlUH7dv6oINIfpGsREof6EqOMYZImtXT4a9ZM7brGolDiLgeb8ZqJw7x 7+Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=7ZHVlh4qk+ldd/FOuzL6cOXR2oVWNlIf7rlUpEiwMBY=; b=GIB5hnPVi8Yx0joVgAT3R8TE+Bsf5kNYNcCn5HSCAhpLJPdA9f2pqgOioAt3kA3Bv1 5UjhTHjG8JjvRYTstnua5ZtshwdHjcnmbcGdy0b+3Oc3GXoPS91TeWRwIJFk8aPuE6Hf 1uvhS2eoe1FdOHbSayJHH05D+ZxiZEZ2PEAL08AacWJ7yKrv37uwCgdJ8Zzd/eGGo62w /r4EHSskMZBfEVo9CXFEFOJeQXZZk8f8pR/5wOyGic9N1S65fzXlDYYj0iNDQLG8OG2y K21LlC+SG9MjLRLA/WVJ0udc435E/angSN1qYN1eMLqkFKswuceA/TqPrxcKlzoZ3Oa4 jy6w== X-Gm-Message-State: APjAAAVe8LmAHZiUpF+Iv8qmFnjFfuQ/wW1C0nf+AWEA22Nb/ksNYc7O Q7FvFN+SOIeCUoKvzYm9s58CSw== X-Google-Smtp-Source: APXvYqwEbObf2IHWOVzbgHc/XM+O+FKARag0HauPDPPtiN9tposNwpeetoOguLTD1lx59yh0P5u4hQ== X-Received: by 2002:a17:902:b407:: with SMTP id x7mr67315149plr.52.1577720920884; Mon, 30 Dec 2019 07:48:40 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([190.95.19.128]) by smtp.gmail.com with ESMTPSA id 133sm51764204pfy.14.2019.12.30.07.48.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2019 07:48:40 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 2BB41300A93; Mon, 30 Dec 2019 12:48:37 -0300 (-03) Date: Mon, 30 Dec 2019 12:48:37 -0300 From: Alvaro Herrera To: Tom Lane Cc: pgsql-committers@lists.postgresql.org, Andrew Dunstan Subject: Re: pgsql: Emit parameter values during query bind/execute errors Message-ID: <20191230154837.GA13289@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2001.1576172486@sss.pgh.pa.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Dec-12, Tom Lane wrote: > Alvaro Herrera 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