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 1w3taH-001eT4-1N for pgsql-hackers@arkaria.postgresql.org; Sat, 21 Mar 2026 10:29:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w3taE-009vxg-2i for pgsql-hackers@arkaria.postgresql.org; Sat, 21 Mar 2026 10:29:31 +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 1w3taE-009vxX-0x for pgsql-hackers@lists.postgresql.org; Sat, 21 Mar 2026 10:29:30 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w3taC-00000000JEG-1BsI for pgsql-hackers@lists.postgresql.org; Sat, 21 Mar 2026 10:29:29 +0000 Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-b8f9568e074so198782466b.0 for ; Sat, 21 Mar 2026 03:29:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774088967; cv=none; d=google.com; s=arc-20240605; b=PKUziUxvfslyMegBIjmdRo+P9aPGqk+9mRYznQNAsn3agDsLbwdLZgmg/73nPB3MXE xAJlA0zJekz3s6jlfceUayIZ9OkmYh9IWrMnAeqvfffcqFzrGw9AUYlDEWu9W8f/+ah5 nYnHVRH2klXFY1CX/ebFA76qAtgfLaU3Pz72scZmwuYucZa8aMt2sPKhjXIU/rXbm1k3 IPS9ny7OsOyt4Xh+DFbOlEYScXAGue+Jz5P0L79wl/jEJ+URrrXmXhaizTi/Ub0mTeRM MQr5RxARwblWj+nW23MtSsJvMgi4izRITg0o9Xfr5ritVZuNeBm4shGvdVWn+DqxA2QO WK1g== 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=7rDB7WbTO+19JXqnD2pgnKqy0hIricDL/QBw6rdac98=; fh=API7pHFvHz//VzzmsjMiZjVU2agzigd09gVcY4RidXg=; b=DKk4kB0BTXvPr3Wfwr+WyGgrmOFnhT2jujdD4bs1kEeuqiY+QgvuIsRS0wGAaM/zzO MJOqAXCAOkRs2ZlJP7aGN5ytMsj0aGcK7cy8+XgEI99hYSD2O4oTkIxv7ReRibgyFstA G8YtoczjAC8YZSCAz4t6Kqcy4bQ4+46qSa9G6/DItpH7ZsA9tYoDUQslZqjmkauOA0Yy ysoHvPjI8QGJW6KkWa1IQbx1+1aDJpaf9VuzFL1PFkUmi3BfrU//wiPzfcPwHtZ+RUxp 7OsMCKwFi+4ehc0FlO0Cht3PAYesGJOcfU8k0IgQUC1f5tOYA2vODgtWYLNzuZAfJ2Sb PwXA==; 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=1774088967; x=1774693767; darn=lists.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=7rDB7WbTO+19JXqnD2pgnKqy0hIricDL/QBw6rdac98=; b=WiYfjpLUja8xYvx3QZh7Abhj8rCW0e8lj2PuRRTwLBloxttA8dvvWlWX0CzfQ4VYXt MIQisvdAH94FntEPCSpRv3FO4gWQZkOpamZTbZWyIsORUapvvLd7awbCx7eqFXZzQ5EW 9XXZENiUe/CxH/M1I6+7XybIUWqPCZyn5S7YduODifFHpuNBdbDw1q08OxcePdC9CxC6 9kYFlOy/V4C2Yy3YOKjt6bifsxuV1QCIBs9D9A5E3SZ1hR7cXSpz8xkcmuGJWse44wqA PtuMbuElC0xyxm5+B5qGZ8Y4tzQgn75Q6v4lKxbhlaUhee+gNvAf3witEvAQWfd3ok6L QS8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774088967; x=1774693767; 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=7rDB7WbTO+19JXqnD2pgnKqy0hIricDL/QBw6rdac98=; b=E8Wmq2fAsJy26bYkyTSMTGVziYRwBZx5v/ZERfUkBQtgjNqZZT61MDBMJx2BBx+oOp 4+YHUtzIOxcmbJtp1l3zHGqWcfkHCUdhBGENLeKa0Bjf+K4/thx9k0Dhq3dUdrcxyElF ClvmlbF4O9SghSMp/rlTK9zOUpqwXqLB4thPzxiyy/Ff8tuGKqICtmG0trryY2t8EG+4 Ojw+Ttlhzo1bva/7nUFkM2rKwT7tYwoVpT7VJ9Whxt+vpQ33gUZJiiHy0pFRJD4UkZFx Ek090xA21rEEv0QK/jI7E/vywSTva/2GzGHg369BZwdS1gii+p2Eww6O1vqKMYA2wd8M uNEA== X-Gm-Message-State: AOJu0Yx3P8PSbykN90N7b9xLK7FfYwtMm+Ke/jZm7MIsChlb2ZaHWxXe bMtWXIjUEmx9DC/+gs4ZG4GT02kTpAzQmvnByuIAuvGL7Q8jirxiuyBx4hh0b00opD/vTrw0oIW Rsi9VVT/WD0vjjYYHV4IKoLXTLm1uEo8= X-Gm-Gg: ATEYQzxI1L2S5h7xeO5KnFgpR5jCdx80ngy8m7rkq8Q/laSKSFqFzJmZRFv41o2UNKV +VLurQ6qbGdJFC1LlzD55LEb+HVyqzp8yfubOcgzQ7jLpTfrLVFqhErzrQFTCB+w5YK//EbOiLE BsD1JwPprLBY6PBVbJ/myjjtudbWqWrT/29xxDhxHm3+cAVX3OevBApkOMiv/ApUVVi1lZjqlx3 pyFhCXzpQGHxgXRE2eFqlE0SLsvRb3gOxEAB/p9kpK8NvbZj1TOIuxKGRdqRxpWIcrB15xSHlnx v4FcI/R9SqLQWE7fgi4uBXczlm95iFyIxQVrwV+bErPIekwHVbWizpOiIkd94rVgnU3mNCDa/VB oC9LIx63A X-Received: by 2002:a17:906:6a25:b0:b98:528b:8461 with SMTP id a640c23a62f3a-b98528b96f9mr71554466b.52.1774088966525; Sat, 21 Mar 2026 03:29:26 -0700 (PDT) MIME-Version: 1.0 References: <0B38B9DC-A53C-437C-B9BD-807F30A032BA@gmail.com> <424A3799-D7FD-4691-BD10-6CBDACB14938@gmail.com> <43825F3D-6156-4030-B5E1-9A0841969022@gmail.com> <260E4616-43B7-4C24-BF53-352DC8DEB7AA@gmail.com> In-Reply-To: <260E4616-43B7-4C24-BF53-352DC8DEB7AA@gmail.com> From: Xuneng Zhou Date: Sat, 21 Mar 2026 18:29:15 +0800 X-Gm-Features: AaiRm52yvoZXHGY0jaMbjhcPEJqaOEdPm-jQ7qcNqvTyfKJJcSBwe9pgZrt00eM Message-ID: Subject: Re: tablecmds: fix bug where index rebuild loses replica identity on partitions To: Chao Li Cc: Postgres hackers 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 Thu, Mar 19, 2026 at 1:07=E2=80=AFPM Chao Li wr= ote: > > > > > On Feb 26, 2026, at 14:59, Chao Li wrote: > > > > > > > >> On Jan 28, 2026, at 10:49, Chao Li wrote: > >> > >> > >> > >>> On Jan 27, 2026, at 16:30, Chao Li wrote: > >>> > >>> > >>> > >>>> On Jan 27, 2026, at 15:59, Chao Li wrote: > >>>> > >>>> > >>>> > >>>>> On Jan 27, 2026, at 15:39, Michael Paquier wr= ote: > >>>>> > >>>>> On Tue, Jan 27, 2026 at 01:13:32PM +0800, Chao Li wrote: > >>>>>> I found this bug while working on a related patch [1]. > >>>>>> > >>>>>> When ALTER TABLE ... ALTER COLUMN TYPE causes an index rebuild, an= d > >>>>>> that index is used as REPLICA IDENTITY on a partitioned table, the > >>>>>> replica identity marking on partitions can be silently lost after = the > >>>>>> rebuild. > >>>>> > >>>>> I am slightly confused by the tests included in the proposed patch. > >>>>> On HEAD, if I undo the proposed changes of tablecmds.c, the tests > >>>>> pass. If I run the tests of the patch with the changes of > >>>>> tablecmds.c, the tests also pass. > >>>> > >>>> Oops, that isn=E2=80=99t supposed to be so. I=E2=80=99ll check the t= est. > >>>> > >>> > >>> Okay, I see the problem is here: > >>> ``` > >>> +CREATE UNIQUE INDEX test_replica_identity_partitioned_pkey ON test_r= eplica_identity_partitioned (id); > >>> ``` > >>> > >>> I missed to add column =E2=80=9Cval=E2=80=9D into the index, so that = alter type of val didn=E2=80=99t cause index rebuild. > >>> > >>> Ideally, it=E2=80=99s better to also verify that index OIDs should ha= ve changed before and after alter column type, but I haven=E2=80=99t figure= d out how to do so. Do you have an idea? > >> > >> I just updated the test to store index OIDs before and after rebuild i= nto 2 temp tables, so that we can compare the OIDs to verify rebuild happen= s and replica identity preserved. > >> > >> I tried to port the test to master branch, and the test failed. From t= he test diff file, we can see replica identity lost on 3 leaf partitions: > >> ``` > >> @@ -360,9 +360,9 @@ > >> ORDER BY b.index_name; > >> index_name | rebuilt | ri_lost > >> ---------------------------------------------------+---------+--------= - > >> - test_replica_identity_partitioned_p1_id_val_idx | t | f > >> - test_replica_identity_partitioned_p2_1_id_val_idx | t | f > >> - test_replica_identity_partitioned_p2_2_id_val_idx | t | f > >> + test_replica_identity_partitioned_p1_id_val_idx | t | t > >> + test_replica_identity_partitioned_p2_1_id_val_idx | t | t > >> + test_replica_identity_partitioned_p2_2_id_val_idx | t | t > >> test_replica_identity_partitioned_p2_id_val_idx | t | f > >> test_replica_identity_partitioned_pkey | t | f > >> (5 rows) > >> ``` > >> > >> With this patch, the test passes and all replica identity are preserve= d. > >> > >> PFA v3: > >> * Enhanced the test. > >> * A small change in find_partition_replica_identity_indexes(): if we w= ill not update a partition, then unlock it. > >> > >> Best regards, > >> -- > >> Chao Li (Evan) > >> HighGo Software Co., Ltd. > >> https://www.highgo.com/ > >> > >> > >> > >> > >> > > > > The CF asked for a rebase, thus rebased as v4. > > Hi, I reproduced this with the test case, and the patch appears to resolve it. Some comments on v5: -- Whether it makes sense to use a single list of pair structs instead of two parallel OID lists (replicaIdentityIndexOids + replicaIdentityTableOids) to avoid accidental desync. -- It would be better to make lock handling in find_partition_replica_identity_indexes() consistent (relation_open(..., NoLock) if child is already locked, and avoid mixed relation_close(..., lockmode)/NoLock behavior). -- Some typos in comments/tests (partion/parition). -- Best, Xuneng