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 1whFzo-0006wd-05 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 00:18:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1whFzm-003npl-1Y for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 00:18:35 +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 1whFzm-003npb-0V for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 00:18:34 +0000 Received: from mail-qk1-x72c.google.com ([2607:f8b0:4864:20::72c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1whFzj-000000008Ly-3jtB for pgsql-hackers@postgresql.org; Wed, 08 Jul 2026 00:18:34 +0000 Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-92e663c828dso6327185a.0 for ; Tue, 07 Jul 2026 17:18:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783469911; cv=none; d=google.com; s=arc-20260327; b=hWKMqVRqrTq+nup9Fkim2FzwTKgdoOAqL2Ln5eIXFnOQt0zZHH551VPy/1CWGiD1E/ pExn9/qqQfc4FOZHHZFA/FoedUGT4OUv8V+L9+E9LsdqQK39ihdTC/FX0L8xUdj4ZQd/ Pa/duh5RoEhDbawMqXoApaIP1JZw2Xyv22r1Uw7HOJiZk1yEh2Lf0L3CxPP/8j2jdLrB h4H48ivK2xK9SaiUfDdQ6ROj7ESfNtR+HTjQHFzrCRRr0f8cfkhI34QMHDo7wyU0pniy 3DJOqY2Grcld/lCgLAWtgrVCtlZmEqqNx5OcAOvQo4269DihjvIB0N0Y845Ow9yBHRav ahrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=r9TipVPayBtMfy3Jk+Cr1MUWipf0VJCB4ihYX6ccabI=; fh=fCaPzKzi5t4lcZUNXW/b7Hld8ph5R8Md4P5AEk0sF9E=; b=AuSwziSEZTyt9QIjC0FYuT5QHl2LVO6UKlio79wn/TM1OfZ2FJwGz2/HR0rqpis9L8 8j+Dygb89rVeIgFz1vMV3kTUlSHKcaiLrb9myYZ/lG2jDME5jW1RtP7ZxwXmg/A6hmnv IGsAZEhHt1eI8tQvjY4oFYzXwpep7E4OzCQwXswGzFR1OZrm0l47kFhcs2IECZ4AiB6v NFeB+cMJCWDPcDBylRby1/PnN7YnsiwMCoKUM1LkRrfIDIzBXibqPSYrjp8v6QfCjaQ4 yquwsRpcWfG23maBrgHB0s89XzNbYsumY3lucdXLqsfrYnc1hwEWZVYPUmPdFbytcGwn SIDw==; 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=1783469911; x=1784074711; darn=postgresql.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=r9TipVPayBtMfy3Jk+Cr1MUWipf0VJCB4ihYX6ccabI=; b=V0q+yLltX682Uj5P9JYe9A2h+SDbBym29OR9DhbgGn7GzfHxOK2Lx3OlOL1YkWoHZx DzzJPU+ev+5/5w4QB0POlpBh5dTj9trQlmIqTl3LQifLRZOkGL4nBqfsz4pkGIdmqeck uIkphFKW500LNIBHd/t60O1vHuTo9ZpR4PNkStEbIltq3NfR3lNe4qOaPb8POXZKADIt v+ni+9xxHTttMlPKV0u1w/lTPt/B9j+FW2WGa+AS4VrEHEHm9S/4t0V2/aqffnkwzR4v QBBwq2+eHf8bmmyIiYF9856VzyzWDdemuQpmvzvq2mbuxjU9JxfVNgtX0D6iMuL0rlwD 4hMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783469911; x=1784074711; h=content-transfer-encoding:content-type: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 :content-type; bh=r9TipVPayBtMfy3Jk+Cr1MUWipf0VJCB4ihYX6ccabI=; b=ieRwc3DDJ/ETZSPXRwp3GRyxh8T1ojPs/JPys/lcHUljm2Ej39agnnOvehZTMUs/6J jJjxV5joLKwjYiU2hqmZak9aIcMk2jUtyi0iNYDC/H9mgTUXnadQMdq/7JlyvhvQzjd0 0ZX7y5havrER5BEQYI9ld3s7Tdl6skO4IWm1S5H2aTASFsQfhwGLWLfdS0dGdMnRPFYL WCH7EzNXkF3DndI7j/yFKaScDa8dpllUO10qExdR6zmqXmPT9v1edRMjHkv5u/tsdTdw 7GiLNu5SeN7wFv9/reQsqbz55Uhb8yqFeXSLDDxRpQxP7lZI9zs9ggAQzbmwFRKL8KL5 cVSA== X-Forwarded-Encrypted: i=1; AHgh+RrRlkMIbpZdWe7Jz/h83FY9fQiSnUySB+Q857QIOkzP8U26axWUdCx7KQQIrO1hy80FSSnkbrBVoX9ELjSr@postgresql.org X-Gm-Message-State: AOJu0YxDBey7EEnKEg7b9PNjbdoakh1WYgoZMmbRV0st8WS749HSf4C4 agFAnp4NMHGRiXA6pXmVQd/jOJqbepuu1kMo5GpmDlrOkxx8OEUWLw/tlfVLuQUYyMOkyp72XN5 fgzmvtGsF1zPs3c2mGWiDwa6RMJNlFEr8rgwfzu/Ezg== X-Gm-Gg: AfdE7ckXQu263GHTPC/tVLMUpXe8iQ9N/hJDsoW1gbnmVE17qUhgUjytEeRln/lUXyP keEhWlKnFaZHl6qKD84BowY6Y85btX5hJL6NgsEj+YQmbDHbxF2vLPHRVlvN8vk6Fw6USXh7cy7 U2JLdEyJttsWyx7SFQVxevEErk01GcqYrkWs25s4Ekv0g+O6hwgBKhr8m99Fs9k+g2nM3CZmcaU SL+tqjqv/Awanbi0iQdovN/Y/oZL6P4kNdn6atdRmnyT06n+i2mL2jxOnC5iP83mEgnAgcWWTVo meQh0fz7I2lw/GnMtpOotS+4jzNqrUW0i+H7YoyvS3fsQpF1NM7aWQVEgWyjkEnMswaEs5ReTxW IwnZzFUDjqri9Ug== X-Received: by 2002:a05:620a:44d4:b0:915:9da9:b541 with SMTP id af79cd13be357-92ec0bbb233mr573798085a.10.1783469910811; Tue, 07 Jul 2026 17:18:30 -0700 (PDT) MIME-Version: 1.0 References: <20260707185751.f9.noahmisch@microsoft.com> <20260707235839.5f.noahmisch@microsoft.com> In-Reply-To: <20260707235839.5f.noahmisch@microsoft.com> From: Alexander Korotkov Date: Wed, 8 Jul 2026 03:18:18 +0300 X-Gm-Features: AVVi8Cdj3bGWCbwEpTuCw1W-vk3uyreR_S8dI7U1CmNvMDOLo5stjglAwLEuRT0 Message-ID: Subject: Re: SPLIT/MERGE use of is_internal=true To: Noah Misch Cc: d.koval@postgrespro.ru, pgsql-hackers@postgresql.org 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 On Wed, Jul 8, 2026 at 2:58=E2=80=AFAM Noah Misch wrote= : > > On Wed, Jul 08, 2026 at 02:49:45AM +0300, Alexander Korotkov wrote: > > On Tue, Jul 7, 2026 at 9:57=E2=80=AFPM Noah Misch w= rote: > > > This and other places in the SPLIT/MERGE patches pass is_internal=3Dt= rue, which > > > ultimately flows to hooks with the following meaning: > > > > > > /* > > > * If this flag is set, the user hasn't requested that the ob= ject be > > > * altered, but we're doing it anyway for some internal reaso= n. > > > * Permissions-checking hooks may want to skip checks if, say= , we're alter > > > * the constraints of a temporary heap during CLUSTER. > > > */ > > > bool is_internal; > > > > > > SPLIT/MERGE constitute user requests to create and/or drop tables, so= they're > > > not like a CLUSTER temporary heap. They should pass is_internal=3Dfa= lse, like > > > when the user runs CREATE/DROP directly. > > > > Thank you for catching this. For sure, we shouldn't pass > > is_internal=3Dtrue here. Attached patch fixes this. I'm going to push > > it if no objections. > > > Subject: [PATCH v1] Don't create SPLIT/MERGE partitions as internal rel= ations > > > > createPartitionTable(), which builds the new partitions for ALTER TABLE > > ... SPLIT PARTITION and ALTER TABLE ... MERGE PARTITIONS, passed > > is_internal=3Dtrue to heap_create_with_catalog(). These relations are > > created at the explicit request of the user, just like a plain CREATE > > TABLE, so pass is_internal=3Dfalse instead. The is_internal flag is me= ant > > for objects created as an internal implementation detail (for example, = a > > transient heap built during CLUSTER), and it is observed by > > object-access hooks. > > > > Reported-by: Noah Misch > > Discussion: https://postgr.es/m/20260707185751.f9.noahmisch@microsoft.c= om > > Log should have a "Backpatch-through: 19" line. Thank you for catching. > > --- > > src/backend/commands/tablecmds.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/ta= blecmds.c > > index 95abaf4890c..0b6a84b32b7 100644 > > --- a/src/backend/commands/tablecmds.c > > +++ b/src/backend/commands/tablecmds.c > > @@ -23137,7 +23137,7 @@ createPartitionTable(List **wqueue, RangeVar *n= ewPartName, > > = (Datum) 0, > > = true, > > = allowSystemTableMods, > > - = true, > > + = false, /* is_internal */ > > = InvalidOid, > > = NULL); > > The edit looks fine for this code site. As I mentioned above, other > SPLIT/MERGE code sites need the same change. This is the only call heap_create_with_catalog() using in SPLIT/MERGE code. But now I see there are calls of other catalog functions with is_internal =3D=3D true. I'll check it more precisely tomorrow. ------ Regards, Alexander Korotkov Supabase