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 1wF59g-004j9M-2y for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2026 07:04: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 1wF59g-0074rO-0L for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Apr 2026 07:04: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 1wF59e-0074qz-2Z for pgsql-hackers@lists.postgresql.org; Tue, 21 Apr 2026 07:04:19 +0000 Received: from m16.mail.163.com ([220.197.31.2]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wF59U-000000022vK-3pBn for pgsql-hackers@postgresql.org; Tue, 21 Apr 2026 07:04:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From: Content-Type; bh=2pRayLnQxjpntj0hBY6vGUdI9mcriBmGFKs/pIEutuw=; b=aUYTwua5J0nkDPa2CADr60wiLq0BL81tDIMI24yLO+Uc4YqqvjDkvC9rSE4rB7 rPCJ5r7jKxaXc9erWzPddzIi5peIRmRZj5j3yH6WIz7eR78Tups+aKvY5jhKoFtg ufLvC+LdOrM9DVmE0jXV1TN4LuDcYmwEvZ+Htuii52dw0= Received: from [192.168.11.136] (unknown []) by gzga-smtp-mtada-g0-0 (Coremail) with SMTP id _____wD332VQIedp9rSXAw--.12953S2; Tue, 21 Apr 2026 15:03:44 +0800 (CST) Message-ID: <258b6521-100e-48da-a7c4-b069ba3df007@163.com> Date: Tue, 21 Apr 2026 15:03:39 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: repack: fix a bug to reject deferrable primary key fallback for concurrent mode To: Antonin Houska , Chao Li Cc: PostgreSQL-development , "Zhijie Hou (Fujitsu)" , Alvaro Herrera References: <10DD5E13-B45D-44F1-BE08-C63E00ABCAC0@gmail.com> <65564.1776696735@localhost> <48844EC6-0909-41E6-B2C4-F3BF8A2B1AA8@gmail.com> <5990.1776751782@localhost> From: Yuchen Li In-Reply-To: <5990.1776751782@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: _____wD332VQIedp9rSXAw--.12953S2 X-Coremail-Antispam: 1Uf129KBjvdXoW7XFWxWF15ZrW5ZrWUJF17GFg_yoWkZFg_CF 9Ykw4DK34UZrWfAanxGw1qqrsrtrZYgr1Yv3yUur1Y93y3Ar95WFWUC3ZavF15Ar4Iv34a v3ZYqr4rGwnF9jkaLaAFLSUrUUUUjb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUvcSsGvfC2KfnxnUUI43ZEXa7IUeEPfPUUUUU== X-Originating-IP: [123.233.246.114] X-CM-SenderInfo: 5ol13upkhqs5l126il2tof0z/xtbC1BCw+GnnIVD5DwAA3F List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 4/21/2026 2:09 PM, Antonin Houska wrote: > Chao Li wrote: > >>> On Apr 20, 2026, at 22:52, Antonin Houska wrote: >>> >>> I'm just thinking if it's worth a separate error message. >>> RelationGetIndexList() just ignores the deferrable PK >>> >>> if (replident == REPLICA_IDENTITY_DEFAULT && OidIsValid(pkeyIndex) && !pkdeferrable) >>> relation->rd_replidindex = pkeyIndex; >>> >>> and if there's no other suitable index, the result is that there is no >>> identity index for the table. So the change attached here should be consistent >>> with this approach. >> Thanks for your review. I guess you read the v1 patch. In v2, I have switched to use GetRelationIdentityOrPK() that Zhijie suggested, which has covered RelationGetIndexList() and all checks, so that code is simplified, and there is no longer a separate error message. > Yes, this looks like the best approach. Sorry for missing v2. > The patch looks good to me. Using GetRelationIdentityOrPK() makes the check match the intended replica identity semantics more closely, and the added regression coverage looks useful. Regards, Yuchen Li