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 1wVQwg-001xMr-2L for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 09:34:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wVQwf-00BRjn-2D for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jun 2026 09:34:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wVQwf-00BRjf-13 for pgsql-hackers@lists.postgresql.org; Fri, 05 Jun 2026 09:34:29 +0000 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wVQwd-00000001Ocr-1J70 for pgsql-hackers@postgresql.org; Fri, 05 Jun 2026 09:34:29 +0000 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-396669329fbso25943481fa.0 for ; Fri, 05 Jun 2026 02:34:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780652066; cv=none; d=google.com; s=arc-20240605; b=CRpnbZ7WYdpd81H8IX43vmuau7sYGocH9QtlLWE0BpJScx2F+Vecu6pCt8FMFoCebB uO4ejzIXH+yNpYuh1DR+0mxEa71ykY/x3dtp6NG8HpWFiYsccXOZmya0D8QF+M1tTca0 Tslb3vSlNSn82cv3tiVS4/Zoprrylb2HnvrEFakfnFSvdmfrhWLi79EEpAKuXnHeIUdy k4gnkOqTltcQfYIADvNNB37y+uuBRp2xNYzbmdgapJJT08Q9s7nVuVz4P9V5e4fQfDys XEWJROvF+9A2q/C5PP628Ln4E06fUcvVmflTMK8nBTA7wwV3h14jxOyFxkfsojGRjZLh sN/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=9//hCFe1HdRJ3QQXSm1Bc+kbV610JeAhnC3I8G1J+fY=; fh=IQPCahtjnkjiwBbEgeh/uG+zQkJCBREyQFaibNumbe8=; b=TWBtcj2ipr/got6Ge8H16oszWYUxCsNSYeNPVwdf6+pReODMcZLJ26ovroQMnZX7UL l3blfYYLg3LHwvAuMFtAy5sdsJO+X+8LKp+eHF+bs1SqpnVvmaciNkv462148evobL6v KLcso3wmAnW7nT672OTvYogWY+RYPECJpBnh5DN7d2IvL9O3WC0LDDJa7lERZZkRiHb+ 80YGkg5C5hbDRo/ZJndTdiKuFUFqx7voOZKuIymmmqje8bZPeq8fSM+gxnGfZf3Q+Pkf 6X5zCFAgxz6sBZKUwH9XjXZjMAP4oLc8f+Un6RjyOwzAZm6eBAD2YUUo+hJw+dtOQSFe vjoA==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jeltef.nl; s=google; t=1780652066; x=1781256866; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9//hCFe1HdRJ3QQXSm1Bc+kbV610JeAhnC3I8G1J+fY=; b=luhzpeKl3eMSDQ/DFyWqhhF55vZ7iGaee8jmLbBkaoFXr09ap/3GGymRzvMWFyRna3 VyD7ccG5sUQXrRWxu06D9brFKzfnsHDHvcXRxOjZIsNUO6qAnkjxhJyJD42V4bKngtyd 41/wRl5beRdi0SImNfoGf4Sbo9d8ymNqEnQDr/WZ9KZrxwwtiJUKs4uamdoulqneJX/E O/7smx+jUO5xMwBpprn/EVNYbae1rYLnvmAiHCCc94T3urU3Yvv8pz2fB7dYey8Hcwap 7WEBzcqDG4se7W6rYcIwBzzjAneJQSY06Z54MHs6ye/f5xL+cuCJTiTZixKGN3puqPwg s0xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780652066; x=1781256866; h=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=9//hCFe1HdRJ3QQXSm1Bc+kbV610JeAhnC3I8G1J+fY=; b=N0g4ZLnYznsCwycue/cr6QjPeUSlLzhgBJGfl6ocXz370lywm9JqIMpoomtnnnjuQK vUZmtdwyHHO7kfJSwysvDUlbpVqiLdFvpGhStahWZZZ4D/Q6lHGEZfX+wbDhs/aWl08w xViMV41ZqzMiz97+wb7Hm0WClDENEiYUTkXTo/JF6LPWVo6IXfM4nFA1IkHbSzf/43zX jBGtHu1t109w8UUndR/Xdl7BJpQGtamrIepu/GTrl5+dGgIflWCAkRRTth20GT6zvQ9o iOkDjl3VKEapkJEHE6Os60jENQ3AUG1/LijLsPV8yWuYe0wrHNircqnJHOps7TeH8XkN EABg== X-Forwarded-Encrypted: i=1; AFNElJ8CC7kRoO3o55l6v3fsbu0QjHJI5P8xPSPQ876LXk0ZaqLt73iETyxY4cCOD9YtlRvK8LC1l1rcOjBo7ntc@postgresql.org X-Gm-Message-State: AOJu0YxSfhv9IEazCowYIelKGVLywPwGoxPydkNQQT0vJxVDq+U6hzWi 6dI2xeKRmiAQ5KgZTKul4YHLSivUBz3OpW+kdJx2cT8JNq5KjYEux7v4R9xVu0MHNsadSEoc0t6 3sGra//bSaFf6sZH/LJQMv/i39b+yIZKRP2xcQ4M5zg== X-Gm-Gg: Acq92OHQTz8v1AOEPekwZzXnzYRzI82mOHgISHFkxObQBFH7G30oENVr8mTvBAixNUH VeKAgRCbVWTns3lTRquuG8oZkZZiIzy3OON5/uUJUVgibEJeDeoHca1nZ8/q3ocQYfbuXWCI9mk 6jBE5MgMU6HVKoqhUfeLekaW5jvtHHefcMmUfQfv7B9xoZ6PDd02sVbR7Lt6ntNXjEgDVQTN65i qyUoCxbcTadiXoj2L2h0W6QzEUoxeY92f83IsTAZnWFktV9rJTT3heFMd3J6FG2itsbi1kZ5PYR WghE53AyEUDFJ3+i X-Received: by 2002:a05:6512:3514:b0:5aa:6ec6:259d with SMTP id 2adb3069b0e04-5aa886bec01mr442454e87.14.1780652066090; Fri, 05 Jun 2026 02:34:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jelte Fennema-Nio Date: Fri, 5 Jun 2026 11:34:14 +0200 X-Gm-Features: AVHnY4LpgMvF_vFz9SFX27PKRAnxjfA6t0VN0XfzlyqZNl_chVpYX0vfqW9u8xA Message-ID: Subject: Re: alert clients when prepared statements are deallocated To: Jacob Champion Cc: Nathan Bossart , pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 29 May 2026 at 19:07, Jacob Champion wrote: > - let drivers pin protocol-level prepared statements so that > application-level DISCARD doesn't touch them > - explicitly separate client and middleware contexts or streams from each other > - rebuild discarded prepared statements opportunistically on a failure I think I like option 2 best (and after that 1). I'm often annoyed that our application layer and protocol layer is so intertwined, so any attempt to separate them is a welcome addition in my opinion. One approach would be to: 1. add an optional additional text field to the Parse message as a kind of "namespace" for prepared statements. Leaving this field out or set to the empty string, would create an "application-level" prepared statement. Setting it to anything else would create a protocol-level prepared statement within that namespace. This would allow libpq to create its own prepared statements, without conflicting with protocol-level statements created by client libraries like psycopopg. 2. Application-level DISCARD/DEALLOCATE would not clean up these namespaced protocol level prepared statements 3. Add a protocol-level version of DEALLOCATE ALL and DISCARD ALL which also clean up all the protocol-level prepared statements 4. Add a protocol-level message to deallocate all prepared statements in a certain schema.