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 1n4660-0004Tt-Dv for pgsql-bugs@arkaria.postgresql.org; Sun, 02 Jan 2022 19:00:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n465S-00087b-G2 for pgsql-bugs@arkaria.postgresql.org; Sun, 02 Jan 2022 19:00:10 +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 1n465S-00087S-6D for pgsql-bugs@lists.postgresql.org; Sun, 02 Jan 2022 19:00:10 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n465O-0003We-Bp for pgsql-bugs@lists.postgresql.org; Sun, 02 Jan 2022 19:00:08 +0000 Received: by mail-lf1-x130.google.com with SMTP id p13so34680766lfh.13 for ; Sun, 02 Jan 2022 11:00:06 -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-language; bh=v+Cab+AVdU8L24Bd3OQnYzM1J6BrL8xuN44oPqwz9fs=; b=ecbfRQ6OeGKAC41cBQ73Mn1do033ByLttnAI+GlXdZoVKP+VpNh+e9hF7MYFtMAPDk oxZWHppAgA/r9rCUtyeE4UjIiaNI51rs4EJQdJV1cXctU8oqlLAysX4BapwFc2ZL/K/z YHRITYLUeHaa6kNZMwWD1G2LpgrgINczT1W3TFK2tnzpgT8EN5sHzQdP8Yng8nLW8TZ8 d9crE16XOq/rXaP2NHex/KfA2qX+3poojiP57t34ERi+N3HFA9jnsPq0VIP+rbe6SiB9 CkRKdjL88G1ZUXfCZIU1oxh8RzlvaSvsP+Ai5eUjlpIVHSqLsmSE+0P1os7X7MrVJCzd DQJA== 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-language; bh=v+Cab+AVdU8L24Bd3OQnYzM1J6BrL8xuN44oPqwz9fs=; b=mV27+4phR9yyY6jp5ItrS+m00/02CJk7FIGkup/G+a2ZLltzszqxTQHy0PiamoGhL7 xIUBb8wdC44mrxLAgvLEFsLoGjY82bRefgIKrqPh9nP+k043fJkl755CLJVKMpy+KEpm U1J8nvdjL5HXPrWe9mGb8W7MRL2N/2O85wIpqngpqWn49zMrBQiU5C+6lOHkCqbeXWsX TeBJp4r1hus6l2KGp59Q0FA83c+BgaEkhRiFxdot5LfGe1Q6Qre5nhQFppfbxeqbe4to q+AoD7uAIPZN4A8rVUlWKu/X6iyCirfbU3bkrtAYAZCd+DDk30wIclotgb3BoWXufMX/ +LXg== X-Gm-Message-State: AOAM530JiFwxX+8UjP82wTZYb6HwLAzkU/wEYrbm9Xnxiugc/vkM/3NJ 4ZaogpJXwYv7sroFecbQ9UipKi9uMWU= X-Google-Smtp-Source: ABdhPJx7cXnUwWIrBENAEWqH4gH6C4BNMvgOSNRWtUWfcZFkdt9LRLFVYyULj71My300PFJFvKwJ2w== X-Received: by 2002:a05:6512:282b:: with SMTP id cf43mr38550285lfb.331.1641150002999; Sun, 02 Jan 2022 11:00:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.6.84]) by smtp.gmail.com with ESMTPSA id a23sm1735760ljk.8.2022.01.02.11.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Jan 2022 11:00:02 -0800 (PST) Subject: Re: BUG #17344: Assert failed on queiring async_capable foreign table with inheritance To: Etsuro Fujita , Dmitry Dolgov <9erthalion6@gmail.com> Cc: pgsql-bugs@lists.postgresql.org References: <17344-226b78b00de73a7e@postgresql.org> <20211225232625.5xuplnlegneh42cw@erthalion.local> From: Alexander Lakhin Message-ID: Date: Sun, 2 Jan 2022 22: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: multipart/mixed; boundary="------------C6F656CCB6955392C3142E41" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------C6F656CCB6955392C3142E41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Etsuro-san, 31.12.2021 10:36, Etsuro Fujita wrote: > On Tue, Dec 28, 2021 at 10:14 PM Etsuro Fujita wrote: >> The root cause of the >> assertion failure in the first case might be something other than the >> limitation. I’ll look into this in more detail. > To fix, I modified postgresReScanForeignScan() so that we always > process a pending async request (if any) before restarting the foreign > scan. Attached is a patch for that. I tested the patch with the > first case, and it addresses the assertion failure. Thanks for the fix! I can confirm that it eliminates the failure and propose a simple test case for the issue. Maybe you will find it useful. Best regards, Alexander --------------C6F656CCB6955392C3142E41 Content-Type: text/x-patch; charset=UTF-8; name="posgres_fdw.sql.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="posgres_fdw.sql.patch" diff --git a/contrib/postgres_fdw/sql/postgres_fdw.sql b/contrib/postgres_fdw/sql/postgres_fdw.sql index ee9ab37d56..9cc13475f6 100644 --- a/contrib/postgres_fdw/sql/postgres_fdw.sql +++ b/contrib/postgres_fdw/sql/postgres_fdw.sql @@ -1935,6 +1935,15 @@ explain (verbose, costs off) select * from bar where f1 in (select f1 from foo) for share; select * from bar where f1 in (select f1 from foo) for share; +-- Check asynchronous fetch with inheritance +alter server loopback options (add async_capable 'true'); +create foreign table foo3 (f3 int) + server loopback options (table_name 'loct1'); +create foreign table bar3 () inherits(foo3) + server loopback options (table_name 'loct2'); +select f1 from foo where f1 in (select f1 from foo3); +alter server loopback options (drop async_capable); + -- Now check SELECT FOR UPDATE/SHARE with an inherited source table, -- where the parent is itself a foreign table create table loct4 (f1 int, f2 int, f3 int); --------------C6F656CCB6955392C3142E41--