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 1nbQkm-00056y-Th for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 17:44:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nbQkl-0002JO-PL for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 17:44:35 +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 1nbQkk-0002JE-Ml for pgsql-hackers@lists.postgresql.org; Mon, 04 Apr 2022 17:44:35 +0000 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nbQkg-0000FC-9l for pgsql-hackers@postgresql.org; Mon, 04 Apr 2022 17:44:34 +0000 Received: by mail-pj1-x102d.google.com with SMTP id bx5so9403946pjb.3 for ; Mon, 04 Apr 2022 10:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yOw32Jn8F4S+jwZdvK74IsBnydf3290SJzWu4cDlgzE=; b=ZSXocsNecTQXu83XLLMRCVnkBZE+xcP59gtLv9sVE6dZRIfPJdVajzwKf0E1auyiKW Bn6+1EjLzDx3hn2/qxfwpJ56lVqQtJWjOriZ0MCTdVElzBza7CH9hGDEl/7CMTFPDP7s XGdQ69GEsuEwwJwse4mAdEab4JBeO4C3X2iEKN+tXywpkJtytTqzoY/P5M3+xBii5o8a 8jackxwFdz0vafMkeP6rw/FyUfyb5Cd1x2MSkn70YeprARTZgUBZUeVUq/5joXB3NHBA dZv5razAu8XzNTrO/1c8slmjO8vQBNeetdH9h9PYybMbUrDQ4iHrJvOzSZOx3Djnzj24 hMZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yOw32Jn8F4S+jwZdvK74IsBnydf3290SJzWu4cDlgzE=; b=bJLMxDSj7AZul2oXqPIYEocLwugp1n+wMqvsZzL9wpw36/jrpqSUFGBZ/7dOgheYbF n5usdkADzS0gzhFvcfkxNwrtJ1DYOLv+qvjAbp4LglWZjvqEZ4WU/mqQuhlBTy3NVhlB Ty5HrrVEC5GpSLQDzZcH/LQ7wsKB84VnrukNybKhwPDwB0ftLeEh4IJM/yYi1VkfE2iB 7WzaOwWJI9etd/H8ZadvfJMSYI4+emHmSqc/Mlt/uQAa90mA2jC/VNBzLwEJEBokrbP3 wZjrIeJYtGG2k27EyM5tzwtQV/YCMvI4lkugEBufW9PWJhK5xUvyz5mTfZYjBdlhDx/L O93w== X-Gm-Message-State: AOAM532wyBPp6nuIdEJXV7ZhnUJUVPGVT+/IEivNe+R/Cyqeb/ZT/3pq 12K3hZUngs/YbB5roIkdu3UCvg3i/wjnqIcDMYV8F3lWbB6j+DvbFQcWRKkpf6dc3JJ821AbBri 4dTFIhWpKhEZk7wxY400F3T7cfQ+QlAF9vvvtXgZ5hUAZ+oEwkTI70MkLdFmcCdGipo49bggwJv wMQHGNSU2Wa4OLkkRM1wvpCIsHIrn6HOVJ8zUI X-Google-Smtp-Source: ABdhPJwCHJG6RRQawlr3Zl4fKnGp2QuHzxswFCokgWTAf3VIpU3uwFj9xtULRLnFXP1A9+2f/7mKdw== X-Received: by 2002:a17:902:7207:b0:153:d860:5c8d with SMTP id ba7-20020a170902720700b00153d8605c8dmr998577plb.40.1649094267392; Mon, 04 Apr 2022 10:44:27 -0700 (PDT) Received: from laptop280-ma-us.hitronhub.home (24-113-193-150.wavecable.com. [24.113.193.150]) by smtp.gmail.com with ESMTPSA id b4-20020a17090a550400b001ca38abb248sm89737pji.53.2022.04.04.10.44.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Apr 2022 10:44:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: New Object Access Type hooks From: Mark Dilger In-Reply-To: <1922986.1649094077@sss.pgh.pa.us> Date: Mon, 4 Apr 2022 10:44:25 -0700 Cc: Thomas Munro , PostgreSQL-development , Joshua Brindle , Robert Haas , Andrew Dunstan , Jeff Davis , Joe Conway Content-Transfer-Encoding: quoted-printable Message-Id: <757EFDF9-FBE3-489C-8CC0-35FD874F7D9A@enterprisedb.com> References: <47F87A0E-C0E5-43A6-89F6-D403F2B45175@enterprisedb.com> <17BD82D7-49AC-40C9-8204-E7ADD30321A0@enterprisedb.com> <1918971.1649091790@sss.pgh.pa.us> <1922986.1649094077@sss.pgh.pa.us> To: Tom Lane X-Mailer: Apple Mail (2.3608.120.23.2.7) X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Apr 4, 2022, at 10:41 AM, Tom Lane wrote: >=20 > Is our CI setup failing to capture stderr from TAP tests?? I'm looking into the way our TAP test infrastructure assigns port = numbers to nodes, and whether that is reasonable during parallel test = runs with nodes stopping and starting again. On casual inspection, that = doesn't seem ok, because the Cluster.pm logic to make sure nodes get = unique ports doesn't seem to be thinking about other parallel tests = running. It will notice if another node is already bound to the port, = but if another node has been killed and not yet restarted, won't things = go off the rails? I'm writing a parallel test just for this. Will get back to you. =E2=80=94 Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company