Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wDCoW-002jBa-21 for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2026 02:50:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wDCoT-003Mo7-1w for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Apr 2026 02:50:41 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wDCoT-003Mny-0z for pgsql-hackers@lists.postgresql.org; Thu, 16 Apr 2026 02:50:41 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wDCoR-00000001FJc-0ZlL for pgsql-hackers@postgresql.org; Thu, 16 Apr 2026 02:50:40 +0000 Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-c70c112cb61so4797714a12.0 for ; Wed, 15 Apr 2026 19:50:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776307838; cv=none; d=google.com; s=arc-20240605; b=DBtgS79Y6yoIFGTF3kKbE9JyzxY1HgXiamxqiK6tL8q0AQRy3qieE8MRchc2XDJAKx gm7ZEhnSOPFvbAXhqf5/TkRS9JFUVftf8kpFZiLAsyy4fdKOHsl10WGCO5Zalo4wC4uM p1eeBQmXegnv1bREBwJOLb/U55ymNgd8FRN8pOZNox0trbkAFyQ+TwnoMmnppxP14b0k mvaDyRKJeOjU6GeEsobhJKR3iUhGSX2KcrhH9ai6bFaP6CNDdwDd3aIO7F3tNUcxgIiS J80fMvNehuRAlhHYUORcHdYpTJ6Rl6LH0o9PJzIl3y3P++YiFp4UvwMsvXgM2qTx/aIL okQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RrxQHgp6qfwR6K9wBxkhsrwW7TfzYh8VrtKu/tFv0DQ=; fh=kAAg1D+PlaIaBuArhHJJbIeTRtmbfEUjMqMDKYdpgAA=; b=celvuKwJO9CVGPoP+knqxQYvWQZtyFLtBGWT25+MeMNnvhCkg2XpNogIrwSz8NgUA8 e0R+n094UnTxuWUcEMFivVFy9hKyNH3TxFzxV3cmtB5Orrn3IOFMu1YMGZvoVdOKaKaA D8VvBCHtJfRCRWBBNEBLXZyLwQnq3jywrXx1QTgeJUb62zqGf2ZbDv94X5rE1QMO+c2f z1Fi+wRyiu//XzUNkSoe0MJYfZBK+qZkqh7NUedCHz0dTpwkNASRWPwGtiZGGVJ4DAo0 w7Z3Qs22Qn6VmkUm8Y5u21mkqBeTJ5RD6q/Nz2/Iv3G99fP0Ktbfl0O1Ps0nR5hAR3T3 kwWw==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776307838; x=1776912638; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RrxQHgp6qfwR6K9wBxkhsrwW7TfzYh8VrtKu/tFv0DQ=; b=COKlVBV4zIwZpCYa25P+FR8EJWFoFfCna2QbdrkMZRA45zhU6MF+PUz7zYWlVZmJ5d i3xlisYQFQtR6mgUotcv54/7n5y/kux+eGe8SZ+qFrU4VuRXEfZLrdfSTbCfiqy5b6m7 w42SjTQTJqOJ089gfbGt4ovYGaU/djmcpkvB5GoiJlSQMimCZ9Hq9S4rq90v0eNnTVGd SZW4BIXbzPQupJPfiD9tTkcStCAKHHuOACbQVticGwr4IO294ov5WlG88zub2n8vVJNg CNgjZqexzjfYboAUw4i0UcSfBZKD26ys7Pq379Y7vCWgNDw5W9Lz82NO2eWOyIQhJCSt CcpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776307838; x=1776912638; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RrxQHgp6qfwR6K9wBxkhsrwW7TfzYh8VrtKu/tFv0DQ=; b=nHhKG56dUFbTb/pfB7nLpHaUhHoTHF0WFfpzFtzoPV0797gbx1E0nTSrbyov+Xiu// qQy8xnBV1o9NiBQzO9Efu2b0nAPfztv1LaaplIujGZMdOiTvRP5gqVQwDC7/ts8GokT2 WY9Ug7X8C4gt8uVpYUgbNaP3LoxyiAeA55PuWh6EP/m6zVtKhsXhIwGqDwXno7VGkm11 4OnQKwbJtBeiSJR2SxXpLQHpgqMNcBxP7c3VuHTarUNnm2+19b37E2WnPJrRyzNnkrQG VNBh4M9lmSJKj84vMmhSAs+m7kvnnevcVPuJei0YmVN278oX62J40/CDxgN4lnGIgs9n F/0g== X-Forwarded-Encrypted: i=1; AFNElJ//xp0nueoJ6F8kPLQcFr/q49KmPosV1/JaBkAvO7SSHWl0gyYhxzWilkLbme96XwqELEUZcMpJcgQ7x0Ce@postgresql.org X-Gm-Message-State: AOJu0YwpBjbSxpWvUMR74lkQERVQKfsTRTpwzE7rZ/ohBSnuvhHKBXCP BURSnF++hqFLiiBsxrzMg4YCzXS1P4XFCSmY9qb8V2dzsByc0TgmqLqg8wvBTgj6tiRqOSHk7y1 0h4wmPx59OhK0yKn/YkrIKUxpMvHuZ08= X-Gm-Gg: AeBDietpycUPfKv9YdaHU95VqBkOx0pShJBSe3DVhjN6rXNPiX/0R+W0PYjTL6OzRst HQImzLQZIjYgt/pql6h8tFh34hsVTDgB20J15cjSEREQHsTPVChe65zwMiOyzf7yUVplSquTlAr YvqdUZVNaEcsMeemHxbKXAmyh0wFiLTTvoGznxwJ7Ygfj7ySAmfFVct/jy9IEzx8mV6sIAvFxX6 UIdOnJfc7Tft5Zx32V5/+2Id76GvkryqfLlqvdD3jYdVZeDpUVNitGylNKSr7KRoZdX0RYWZ1Sh 1mnFjZkWFjn3Nm85n5D/0BcAXdrgxeZ0ANda+JPwAGzODyOAvD/8aWlWaa9raXCHCkzpb3YZchg = X-Received: by 2002:a05:6a20:4312:b0:39f:2307:8a2d with SMTP id adf61e73a8af0-39fe3c911femr27186245637.12.1776307838490; Wed, 15 Apr 2026 19:50:38 -0700 (PDT) MIME-Version: 1.0 References: <6B155E97-EDE7-4CBE-8196-E709F6A4B33D@gmail.com> In-Reply-To: <6B155E97-EDE7-4CBE-8196-E709F6A4B33D@gmail.com> From: Amit Langote Date: Thu, 16 Apr 2026 11:50:22 +0900 X-Gm-Features: AQROBzD2rzL9gp4Wb67gNI4LtigOIxlqFIPCPcQKb5VQY56Wum0yr7d6X3lOPhc Message-ID: Subject: Re: GetCachedPlan() refactor: move execution lock acquisition out To: Chao Li Cc: Kirill Reshke , PostgreSQL-development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Thu, Apr 16, 2026 at 11:35=E2=80=AFAM Chao Li w= rote: > > On Apr 15, 2026, at 21:46, Amit Langote wrote= : > > On Wed, Apr 15, 2026 at 11:14=E2=80=AFAM Amit Langote wrote: > >> On Wed, Apr 15, 2026 at 1:08=E2=80=AFAM Kirill Reshke wrote: > >>>> +static bool > >>>> +LockCachedPlan(CachedPlan *cplan) > >>>> +{ > >>>> + AcquireExecutorLocks(cplan->stmt_list, true); > >>>> + if (!cplan->is_valid) > >>>> + { > >>>> + AcquireExecutorLocks(cplan->stmt_list, false); > >>>> + return false; > >>>> + } > >>>> + return true; > >>>> +} > >>> > >>> simply `return cplan->is_valid ` would be more Postgres-y here, isnt = it? > >> > >> Agreed, will fix too. > > > > Thinking more about this bit, checking only cplan->is_valid after > > locking is not really equivalent to what CheckCachedPlan() was doing > > before. > > > > CheckCachedPlan() can also reset plan->is_valid based on other state > > (role, xmin), whereas in v1 the new check relied only on lock inval > > callbacks to have set is_valid to false. That means the new check is > > not enough. It may happen to be okay for the current callers in this > > patch, but it is not something I think is safe to rely on once there > > are future callers that do arbitrary work, such as ExecutorPrep(), > > even if carefully coded, between the original GetCachedPlan() / > > CheckCachedPlan() step and the later recheck after locking. > > > > Separately, I also realized that v1 was introducing redundant lock > > acquisition for freshly built plans, which is not really a no behavior > > change refactoring either. > > > > So in v2 I ended up reworking two parts more substantially: > > > > * The patch now factors the reused-generic-plan validity logic into > > RecheckCachedPlan(). > > > > * It also adds an is_reused output argument to GetCachedPlan(), so > > callers can distinguish the reused-plan case from a freshly built plan > > and avoid the extra lock step in the latter case. > > V2 overall looks good, it preserves the current behavior. > > I just have a question. RecheckCachedPlan is only called by LockCachedPla= n and CheckCachedPlan, and both callers are static, why RecheckCachedPlan i= s exported? Oh, I thought someone would ask that. Yes, it could stay static in plancache.c for now and only be exported later, when some future smarter cached-plan locker outside plancache.c actually needs it. -- Thanks, Amit Langote