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 1pPhkB-0005Mk-IU for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Feb 2023 10:32:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pPhkA-0006Gu-EQ for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Feb 2023 10:32:02 +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 1pPhkA-0006Gl-2y for pgsql-hackers@lists.postgresql.org; Wed, 08 Feb 2023 10:32:02 +0000 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pPhk5-0005dJ-OW for pgsql-hackers@postgresql.org; Wed, 08 Feb 2023 10:32:01 +0000 Received: by mail-pf1-x42e.google.com with SMTP id 203so12759573pfx.6 for ; Wed, 08 Feb 2023 02:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=y+yTu8hmWU6AVWdeQlfqKgIsuvALDau7aPs3ICfZQts=; b=owHrllgdBbjD6ogUc6A8RDA/wJjL/pqBcfnhcbqz4aeoEK6+duahrELQn+kPCjGXtk SD3nD0HMrO6YSLHSeZIZvau2sal3CmpN35cM3Sy1wivqmbq9ZSNf0C+EdXO9+LQzn1Im HzujP88Z5lNvHB4SPurh4qs6KhjEBfykmtb0RKBXolrUVUIsDozieSXx/RbpL6hn+KWA LUtPCz3KApOfmaZ49l0aaPvXo2g6cF++u5/lz/xdfJ7ffOkTvr8f6KM4oaAsu0MJ2Xck SEJGwrGZUbtOAeZcFZ1ffNQ93BPiCTBAHCquj40SbslZbrrQuHP6MZb2cHY3PB99aaVp 4Jiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=y+yTu8hmWU6AVWdeQlfqKgIsuvALDau7aPs3ICfZQts=; b=sbmtuAMLkYD0ZzToasGzxyTanEGICyzmXLG2HFRJlMA0JCrOZi3zrh6MtvLQjX04zl Mv7kRVMis8MdhlM1WT5JgkipSwSM3lmQz2EkoPe2U4lajMo91NkJ9Q7KmlvzJX0kM9da 68jd1B24e+Fal3ka7vmkntAhtGDoML5PtfhZiWeVGyZXh4SzqAucypCRLOHwX4V5917M tsIYmGS3AiZoMB87LBagTzGRiVgkgRmVTsvCmcpEcPTf7CXIOaj2kF8SmCxrsmjo/m05 iJoZ8z92hZvsTIy0PLYly6XWjB6l4GiBAjlDUvexhDusaPiAtxLyjIo6ZvdlT1cd+RJ2 fCkg== X-Gm-Message-State: AO0yUKXM4QlOfTIkLJNHDyaFK42tFNVnGRHyfkzJUl6uwKpV+xR+oLTh joSDayPce62J01ZUbY9TDkT6sleDl43j8V4jzio= X-Google-Smtp-Source: AK7set865mO2Ajb91HPz92BchBivjh4dQkChshXvy+wnQoXrnz7F36WxH73GexLbJ0D2UsZG3khkQ4lSo2LO5NBbneU= X-Received: by 2002:a62:1495:0:b0:5a8:49c8:122e with SMTP id 143-20020a621495000000b005a849c8122emr167234pfu.5.1675852315073; Wed, 08 Feb 2023 02:31:55 -0800 (PST) MIME-Version: 1.0 References: <20221221101846.7zsi7lscnm5ediik@alvherre.pgsql> <1350682.1671635927@sss.pgh.pa.us> <4191508.1674157166@sss.pgh.pa.us> <349124.1674185509@sss.pgh.pa.us> <20230207180855.xy5m4puwh5gzd7xy@awork3.anarazel.de> In-Reply-To: <20230207180855.xy5m4puwh5gzd7xy@awork3.anarazel.de> From: Amit Langote Date: Wed, 8 Feb 2023 16:01:30 +0530 Message-ID: Subject: Re: generic plans and "initial" pruning To: Andres Freund Cc: Alvaro Herrera , David Rowley , Jacob Champion , PostgreSQL-development , Robert Haas , Tom Lane Content-Type: multipart/alternative; boundary="000000000000efa8e105f42dc532" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000efa8e105f42dc532 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 7, 2023 at 23:38 Andres Freund wrote: > Hi, > > On 2023-02-03 22:01:09 +0900, Amit Langote wrote: > > I've added a test case under src/modules/delay_execution by adding a > > new ExecutorStart_hook that works similarly as > > delay_execution_planner(). The test works by allowing a concurrent > > session to drop an object being referenced in a cached plan being > > initialized while the ExecutorStart_hook waits to get an advisory > > lock. The concurrent drop of the referenced object is detected during > > ExecInitNode() and thus triggers replanning of the cached plan. > > > > I also fixed a bug in the ExplainExecuteQuery() while testing and some > comments. > > The tests seem to frequently hang on freebsd: > > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%= 2F3478 Thanks for the heads up. I=E2=80=99ve noticed this one too, though couldn= =E2=80=99t find the testrun artifacts like I could get for some other failures (on other cirrus machines). Has anyone else been a similar situation? > > --=20 Thanks, Amit Langote EDB: http://www.enterprisedb.com --000000000000efa8e105f42dc532 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 7, 2023 at 23:38 Andres Freund <andres@anarazel.de> wrote:
Hi,

On 2023-02-03 22:01:09 +0900, Amit Langote wrote:
> I've added a test case under src/modules/delay_execution by adding= a
> new ExecutorStart_hook that works similarly as
> delay_execution_planner().=C2=A0 The test works by allowing a concurre= nt
> session to drop an object being referenced in a cached plan being
> initialized while the ExecutorStart_hook waits to get an advisory
> lock.=C2=A0 The concurrent drop of the referenced object is detected d= uring
> ExecInitNode() and thus triggers replanning of the cached plan.
>
> I also fixed a bug in the ExplainExecuteQuery() while testing and some= comments.

The tests seem to frequently hang on freebsd:
https://cirrus-ci.com= /github/postgresql-cfbot/postgresql/commitfest%2F42%2F3478
=

Thanks for the heads up.=C2= =A0 I=E2=80=99ve noticed this one too, though couldn=E2=80=99t find the tes= trun artifacts like I could get for some other failures (on other cirrus ma= chines).=C2=A0 Has anyone else been a similar situation?
=
--
Thanks, Amit LangoteEDB: http://www.= enterprisedb.com
--000000000000efa8e105f42dc532--