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 1n62tr-0003CM-KN for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Jan 2022 04:00:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n62tp-0007cb-85 for pgsql-bugs@arkaria.postgresql.org; Sat, 08 Jan 2022 04:00:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n62to-0007cS-Ut for pgsql-bugs@lists.postgresql.org; Sat, 08 Jan 2022 04:00:13 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n62tl-00043X-Er for pgsql-bugs@lists.postgresql.org; Sat, 08 Jan 2022 04:00:11 +0000 Received: by mail-lf1-x12b.google.com with SMTP id k21so22664744lfu.0 for ; Fri, 07 Jan 2022 20:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/+Pwe5n/QvESoCxbO8vugmym480FHxsfY4/AKSPQVdQ=; b=GBf6Khf+wFVuWevrQaTfuHW1KN8fU4sEct1A6dt8Es7tuN8Y8Bda3g2HYZnp8mGQv5 VnMis2HRpgPYnRh2ltroEcCc3A7s49qHOWkNSwSg5XR9e+lAoh2rz+ygjT8mNRN5e+BK ePPLZYRwZzpUkjg4/TUbKiaEQlS+F0MNgbMiaeNbx1kjwFXXyaye+J9rNp69RYhz/S3T 1KCgx6Eu6FQwgxh4MvKFL+j/Ei4fVsCUtp9WzCQJNrXmRgRffgoCz+VoLixsBQ6dRxfu PYZwohqJ6QKx1UChXVr2tYbrzCMctbCtHK3Ax+waRMwTFGHFvH+sIWz8igY3ZCCov3Vk RKBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/+Pwe5n/QvESoCxbO8vugmym480FHxsfY4/AKSPQVdQ=; b=uuAM9jOSiv+qKycW0xrMK+yMyiSgv2VZshXXkrKcvFC+l+Il3KBPSPPS/iSzx29hlZ VphQSjT+KQ46r5ygVf95ahYdUum/vfDmwKAyUVckxKTgiZVgUPRev+xxUBWdw9g65evh iiPqNPcD6RFSzgQZpwO9resS5qf46K/i3D6+nqUzC/DJs0KuJuCLnHyH3rGOLS4T0g1s 5It6dTa02rZJStVQSVvh9EL3CQi/uGjU3qm7G17AS1k2jMIBUrNmp/gkvW9ljH8hNp3J Rw66g7Whq0tCGydTqvj9IH7b7uyuQP6YW1FjBbTbOfxUmsSmWyOaeOB70HQHmzew0QRx 6Fkg== X-Gm-Message-State: AOAM533jqr9MySWKUTgMzBW8E6LKQc2hGKw5S+eJSasI5fEcJxgTMbaL zE+jXfYf29QdHcp4UOOoQfMKmycya5g= X-Google-Smtp-Source: ABdhPJybWHSJ3stphSlK17nlftSS2NnwVLE3P2v2w1KUFuHaEzwQ0hy/YKVHWtUJnUKTFxiZsRKNUA== X-Received: by 2002:ac2:5e70:: with SMTP id a16mr58452829lfr.238.1641614407739; Fri, 07 Jan 2022 20:00:07 -0800 (PST) Received: from [1.0.0.7] ([178.155.6.84]) by smtp.gmail.com with ESMTPSA id x14sm66085ljh.15.2022.01.07.20.00.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 20:00:07 -0800 (PST) Subject: Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance To: Etsuro Fujita Cc: Dmitry Dolgov <9erthalion6@gmail.com>, pgsql-bugs@lists.postgresql.org References: <17344-226b78b00de73a7e@postgresql.org> <20211225232625.5xuplnlegneh42cw@erthalion.local> From: Alexander Lakhin Message-ID: Date: Sat, 8 Jan 2022 07:00:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 07.01.2022 09:15, Etsuro Fujita wrote: > On Mon, Jan 3, 2022 at 4:00 AM Alexander Lakhin wrote: > >> propose a simple test case for the issue. Maybe you will find it useful. > Thanks, but in my environment, the test case doesn’t cause any > failure. It's interesting. I perform on REL_14_STABLE (61c8da50) the following: wget https://www.postgresql.org/message-id/attachment/129455/posgres_fdw.sql.patch -O - | git apply ./configure --enable-debug --enable-cassert >/dev/null && make -j8 >/dev/null && make -j8 -C contrib >/dev/null && make check -C contrib/postgres_fdw/ and get: test postgres_fdw                 ... FAILED (test process exited with exit code 2)     1116 ms > How about something like the attached, which is made by > modifying the original test case to avoid the connection-limit-error > issue. In the attached, I also added a comment to a function to match > other places. Your modified test fails with unpatched postgres_fdw.c too (as expected). I would prefer your test as more elaborated. Best regards, Alexander