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 1vhtUC-0096zJ-34 for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Jan 2026 17:56:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vhtUC-00E6gT-0B for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Jan 2026 17:56:20 +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 1vhtUB-00E6gK-29 for pgsql-bugs@lists.postgresql.org; Mon, 19 Jan 2026 17:56:20 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vhtU9-001HR5-1J for pgsql-bugs@lists.postgresql.org; Mon, 19 Jan 2026 17:56:19 +0000 Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-34c2f335681so2374514a91.1 for ; Mon, 19 Jan 2026 09:56:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768845377; cv=none; d=google.com; s=arc-20240605; b=NaEvaLAqrHZYod4B9Lrlvldm/dsANu5E0CrCJ01eqNaZL6K8uE6J4riopbGUKjiel3 dvNlbq3W3pP2lm6QPkr63EIbbhYMnakrOegNQyj+JVhMoBXtdYakQ9zbjwqUhUgNVkOT oz4JqTYJgP7w1T9UvcTy+WBu9nGy+sQVaMEB2Mtqmzchp9T0IvydX8c2GPI/N3q8c1O5 rszPR8kOcppePjgBtlY7ZYTHDqyN6jqvcmaetobGKdnitPXR0Sqsh2wbtKtDbB3zc3VZ 3ntqsayPMEWzKixelsq6Sy2+sA3Vqajgpa+pWSZXHFHiUffFI6n/tq3SMEMPG5o8IO5/ yV7w== 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=Y9+2xN0wlpqxwVOzuLuHaxIzkg80ls79aW/4P8LoPk8=; fh=o0eBcsck9D9LkTgpEDwDxDh058kXkgHuI6ZMRiwRDfA=; b=V3ItUo6rGXet5u3fa+0l1KD8DJc+Zhp28MVhjhVIQFynLQI2IthGqF18Uthl1XRq27 0em4cSNZk/bd/7X7nNPwaud2JgdmxqHGMHFTOZO1dnY2/Y5vdl+HtaiocTNiDCOxkm+X ze9l5+lewSKamSflCR8XCZKqyU333gtDkrw95wxzNRO4lF9bRjtNY+4vIrJkgTvgUsLp 9/4x4NKgzM9QK7NvLlXY8TYy17vx0thNrZW6dVgrDmG22TioSI15uZdopyxb7eZbDjWL F2uskFZO1vQVAbUfWwHuxaS9pjjYwKsiydRyrhiQOndtiuguAgoMaYtkCzyALgM8hHkd //cQ==; darn=lists.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=20230601; t=1768845377; x=1769450177; darn=lists.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=Y9+2xN0wlpqxwVOzuLuHaxIzkg80ls79aW/4P8LoPk8=; b=J2bnpptZQ4zYt1gzqaKgovtJa4pkBshZwwCZDgEwCSgyXzqN92zQjLAnQO7gljADJI vv/OTHTW2SmJw2kBnVQl8feeiwOToh7EhFetF5QEVTIb2GU+8KKJkUnpgEujuh80mXTA VQ5/4W5ttNQ3X3t0jbJk+Nm4PobsbOvrNrikWOUjAV1fZOPv7r+FvxciV82tz32A2k/M Kd7TWzjDLLeqbYdo61QKogK9ZKvFn2dpo0RafJt+/vTt0Fip9pY9cFt9dUdrb3iQjtam jdd6y/QWOmehct6vztKOOoKRLvoPNgW+dAbNcTzQkZ4W26+KZBWKgFxSKTp7PKp6qLl4 XOzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768845377; x=1769450177; 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=Y9+2xN0wlpqxwVOzuLuHaxIzkg80ls79aW/4P8LoPk8=; b=bqBjdlTZjsPKbo3KzDIn5VroaxWT95e2uScV7ws9cTGmR+9PxkIMNbZa/URxAQljRx czTiJ2skJsuh0bbGrrRBIlZFtQEA/joK1oBiZm+SVH2lqu/5CxM7YfUjs333baw5+vck if8GutXjWAawUAlyMqaQt7C2HrwR+byoOJdUAFNJDkTCTkMRQUAgGpx2l1kzpLtPtPF3 0zxX9jZed9uThpI36YJsgeUX4Zc3KdHal+wKvK3Nj2YQ9ErEHReajv8Mo6oAeX+yotqS mdyXFFlGShLNMGb5mN5KcJ4NewJL2CYs6fcJvvQduuxBIC0eH16MYdYkexcQCY70XQ95 56rQ== X-Forwarded-Encrypted: i=1; AJvYcCWDU6jocZ5mwpnyI465cSPMTq8Cge3VYF2ZxLTw+zN8jEOV9JRwlEumbw1PjpUqlj+WxtxCCa8O4CnS@lists.postgresql.org X-Gm-Message-State: AOJu0YwD3u7jMkLXwoDBEk7NFaBDA2t0gCSd83jCLrQmUZcUQc6u+TUC XsKax5bmBRY8pwOIzBXh3ro4JsNnLWZU1RVO5KoozXaAgGQ/TIYNSMoi1mP3dafEGRt5x26Q4L+ 6p5wZ5oPL11Vs8R0iXuJIj3pPXuXc2sk= X-Gm-Gg: AZuq6aLDLdNae8naClCWpVlyQSXzFsGkpe9wCrVKcNWRUj9t6pY5Wj+qIsmJQoG6OEx QfOCQSu1esCM1bLUClPvO6EEUx5o05Vv8Aa5n18gLfEe/CKX5oc1yYb3dBVzXhsjZjaKxo9omO8 vl0FlZrjw14Pu2MyNJFAl5M/eqV/KKOmZC1p75UnYCejJi+ERD55UxNj0geDIbMptdym5QPZdz9 nV5hT4m5DKFtx5RysqpdyPj/2EqRO+1xh+O0XprIHQAUX1ERPcmI82HKuGKkrLQax7wMmzd X-Received: by 2002:a17:90b:4d8d:b0:32a:34d8:33d3 with SMTP id 98e67ed59e1d1-35273041641mr10693466a91.0.1768845377040; Mon, 19 Jan 2026 09:56:17 -0800 (PST) MIME-Version: 1.0 References: <19099-e05dcfa022fe553d@postgresql.org> <2960545.1761800903@sss.pgh.pa.us> <3017911.1761832112@sss.pgh.pa.us> In-Reply-To: From: Amit Langote Date: Tue, 20 Jan 2026 02:56:05 +0900 X-Gm-Features: AZwV_Qj5sUFHj5j_HPGYkDe42B03eKwAdQB6fIVNcHtYg0c7eF_PNKKJpTbWPGg Message-ID: Subject: Re: BUG #19099: Conditional DELETE from partitioned table with non-updatable partition raises internal error To: Tender Wang Cc: David Rowley , Tom Lane , Kirill Reshke , jian he , Alexander Lakhin , PostgreSQL mailing lists Content-Type: multipart/alternative; boundary="0000000000005c779a0648c1685c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000005c779a0648c1685c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 16, 2026 at 4:57=E2=80=AFPM Amit Langote wrote: > On Wed, Jan 14, 2026 at 10:38=E2=80=AFPM Amit Langote wrote: > > On Wed, Jan 14, 2026 at 9:30=E2=80=AFPM Amit Langote wrote: > > > Attached is an updated version with improved comments and simplified test cases. > > > > > > Regarding back-patch safety (to v14 where the bug was introduced): > > > > > > * EXPLAIN VERBOSE output order changes (ctid now appears before tableoid) > > > * AddForeignUpdateTargets is no longer called when the FDW doesn't > > > support the command > > > > Hit send too soon re the 2nd bit I guess. Actually we can just return > > false when AddForeignUpdateTargets is missing, so the callback is > > still called when present. > > > > Updated patch attached. > > To summarize, the two approaches we've thought about: > > 1. Executor-side fix > (v4-0001-Fix-bogus-ctid-requirement-for-dummy-root-partiti.patch > posted with my Nov 8 email): > > Make ExecInitModifyTable() not require ctid when the only result > relation is a dummy partitioned root. This is minimally invasive but > leaves EXPLAIN VERBOSE output inconsistent depending on > enable_partition_pruning -- with pruning off, you see tableoid but no > ctid, while with pruning on, you see ctid. That's confusing for users > as mentioned upthread. > > 2. Planner-side fix > (v4-0001-Fix-row-identity-handling-for-dummy-partitioned-r.patch > posted with my last email): > > Don't add tableoid for child relations that don't contribute > row-identity columns. This keeps root->row_identity_vars empty when > there exists only one such child relation, so > distribute_row_identity_vars() can add ctid for the dummy root. > EXPLAIN output is consistent regardless of pruning setting. (Some may > notice in the patch that there's still a minor change, but that's due > to how explain.c decides whether to print the table name before the > column name, which is unrelated to this.) > > I'm inclined to go with the second approach. The only back-patching > concern is that EXPLAIN VERBOSE output order changes (ctid now appears > before tableoid). This is cosmetic -- junk columns are looked up by > name, not position -- but could affect tests or tools that parse > EXPLAIN output by position. > > If there are no objections, I'll commit patch #2 next week. Tom, do you have any thoughts on the above? --=20 Thanks, Amit Langote --0000000000005c779a0648c1685c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jan 16, 2026 at 4:57=E2=80=AFPM Amit Langote <amitlangote09@gmail.com= > wrote:
> On Wed, Jan 14, 2026 at 10:38=E2=80=AFPM Amit Langote <amitlangote09@gmail.com> wrote:
> > On Wed, Jan 14, 2026 at 9:30=E2=80=AFPM Amit Langote <amitlangote09@gmail.c= om> wrote:
> > > Attached is an updated version with improved comments and si= mplified test cases.
> > >
> > > Regarding back-patch safety (to v14 where the bug was introd= uced):
> > >
> > > * EXPLAIN VERBOSE output order changes (ctid now appears bef= ore tableoid)
> > > * AddForeignUpdateTargets is no longer called when the FDW d= oesn't
> > > support the command
> >
> > Hit send too soon re the 2nd bit I guess. Actually we can just re= turn
> > false when AddForeignUpdateTargets is missing, so the callback is=
> > still called when present.
> >
> > Updated patch attached.
>
> To summarize, the two approaches we've thought about:
>
> 1. Executor-side fix
> (v4-0001-Fix-bogus-ctid-requirement-for-dummy-root-partiti.patch
> posted with my Nov 8 email):
>
> Make ExecInitModifyTable() not require ctid when the only result
> relation is a dummy partitioned root. This is minimally invasive but > leaves EXPLAIN VERBOSE output inconsistent depending on
> enable_partition_pruning -- with pruning off, you see tableoid but no<= br> > ctid, while with pruning on, you see ctid. That's confusing for us= ers
> as mentioned upthread.
>
> 2. Planner-side fix
> (v4-0001-Fix-row-identity-handling-for-dummy-partitioned-r.patch
> posted with my last email):
>
> Don't add tableoid for child relations that don't contribute > row-identity columns. This keeps root->row_identity_vars empty when=
> there exists only one such child relation, so
> distribute_row_identity_vars() can add ctid for the dummy root.
> EXPLAIN output is consistent regardless of pruning setting.=C2=A0 (Som= e may
> notice in the patch that there's still a minor change, but that= 9;s due
> to how explain.c decides whether to print the table name before the > column name, which is unrelated to this.)
>
> I'm inclined to go with the second approach. The only back-patchin= g
> concern is that EXPLAIN VERBOSE output order changes (ctid now appears=
> before tableoid). This is cosmetic -- junk columns are looked up by > name, not position -- but could affect tests or tools that parse
> EXPLAIN output by position.
>
> If there are no objections, I'll commit patch #2 next week.

Tom, do you have any thoughts on the above?

--
Thanks, Amit Langote
--0000000000005c779a0648c1685c--