Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jXoN6-0002M3-BG for pgsql-hackers@arkaria.postgresql.org; Sun, 10 May 2020 16:00:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jXoN5-0003Mf-9c for pgsql-hackers@arkaria.postgresql.org; Sun, 10 May 2020 16:00:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jXoN5-0003MY-2a for pgsql-hackers@lists.postgresql.org; Sun, 10 May 2020 16:00:07 +0000 Received: from mail-lj1-x241.google.com ([2a00:1450:4864:20::241]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jXoN3-0001dj-2H for pgsql-hackers@postgresql.org; Sun, 10 May 2020 16:00:06 +0000 Received: by mail-lj1-x241.google.com with SMTP id a21so6785946ljj.11 for ; Sun, 10 May 2020 09:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=mZMltqe0XdeU7do8n2IPDd48fLFoR5Zh794pSfVy5Ac=; b=eivL80YfyE3LEnSM8y+B+bgkyrro8CRe+fWVtuO3bZdFklaPwiavCi24zXu0+OCIrF VVrK5SJZycL8CMQyknkvBuwCB2UYbOW3BtjilDeI1GpGjepiUDhBo6hAtFMRZn2J2S/e EY5quJzdsqGJOVUhr3xQH5gBZoDnYo+T8cAv4NQEE1zxuvxCcH0hXZfSEb2OQ6RF/ob1 dmepw9I5j7387B5lDOz7x66zXZ9Jfzo7l0T4VmGFOZ2ktaus+QyPvG4WioBdwIqGRKwp OPovzSzRQuPrwd45p/1E7vfaKI3z+P2r7nuokaL/O+FE5IRi13EV3RWwNgBe8euuTaLf UUoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=mZMltqe0XdeU7do8n2IPDd48fLFoR5Zh794pSfVy5Ac=; b=EbOFAidREt6ukvNqBMckVRrMaJ0dcrfr9lC2YYHMops9VuSidgWRkvUwLIy5cFuYk2 ChlLsVuBNe0Fbe4dSSZpk83p0TbqAOscpfPexnMNULgK7v5SP+Jf8mcQScVBV23Mm4St GS7TGNLGPI9gnwzLXW4cTxoA2Zd6EDcmpZ5VM+eVvR9zX71nYJ+lcA+RrzRWJpSpBQEc mNhxUoiwzRDwY1LdPTlMjh12XkkNXd0tw8QoLpDwmPim4qtQ2HTfcjeOh3FwuHEkus5I rRfZWLNUNvup25gAaXgPJATgrj0l6pT5d0fc1U68/c/YcHIjBVSekx1rVh83f83IyshO J1aA== X-Gm-Message-State: AOAM532BznoRpcpkr5S+xJLmuHLl9BFbQmWTdUO8FWrQCNHoVroZfqrG Uz3ajaKlbkuwosGXOdza9pk1aP6+ X-Google-Smtp-Source: ABdhPJxAQ/2abyh2a65x5q4DngDaiJqujyl5HIOnMSCSAR6/amEwEk652xxGqbvmnCisNNtXKlNtDA== X-Received: by 2002:a2e:88d8:: with SMTP id a24mr7685625ljk.224.1589126403221; Sun, 10 May 2020 09:00:03 -0700 (PDT) Received: from [1.0.0.7] ([178.155.6.211]) by smtp.gmail.com with ESMTPSA id n2sm7588010lfl.53.2020.05.10.09.00.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 09:00:02 -0700 (PDT) To: pgsql-hackers From: Alexander Lakhin Subject: gcov coverage data not full with immediate stop Message-ID: <816a4de5-3f15-4d66-1ec1-791cab2ca6df@gmail.com> Date: Sun, 10 May 2020 19:00:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------82EDD5792E8E252B2FD3E067" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------82EDD5792E8E252B2FD3E067 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello hackers, I've found that gcov coverage data miss some information when a postgres node stopped in 'immediate' mode. For example, on the master branch: make coverage-clean; time make check -C src/test/recovery/; make coverage-html generates a coverage report with 106193 lines/6318 functions for me (`make check` takes 1m34s). But with the attached simple patch I get a coverage report with 106540 lines/6332 functions (and `make check` takes 2m5s). (IMO, the slowdown of the test is significant.) So if we want to make the coverage reports more precise, I see the three ways: 1. Change the stop mode in teardown_node to fast (probably only when configured with --enable-coverage); 2. Explicitly stop nodes in TAP tests (where it's important) -- seems too tedious and troublesome; 3. Explicitly call __gcov_flush in SIGQUIT handler (quickdie)? Best regards, Alexander --------------82EDD5792E8E252B2FD3E067 Content-Type: text/x-patch; charset=UTF-8; name="pgnode-stop.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pgnode-stop.patch" diff --git a/src/test/perl/PostgresNode.pm b/src/test/perl/PostgresNode.pm index af13c320e9c..99c1e85e1a3 100644 --- a/src/test/perl/PostgresNode.pm +++ b/src/test/perl/PostgresNode.pm @@ -1242,7 +1242,7 @@ sub teardown_node { my $self = shift; - $self->stop('immediate'); + $self->stop(); return; } --------------82EDD5792E8E252B2FD3E067--