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 1w8b0c-000gxf-2S for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2026 09:40:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8b0b-00B8XB-1l for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Apr 2026 09:40:09 +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 1w8b0b-00B8X1-0Y for pgsql-hackers@lists.postgresql.org; Fri, 03 Apr 2026 09:40:09 +0000 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w8b0Y-00000000Ls6-3XaB for pgsql-hackers@postgresql.org; Fri, 03 Apr 2026 09:40:09 +0000 Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-c76bde70ec9so698864a12.2 for ; Fri, 03 Apr 2026 02:40:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775209205; cv=none; d=google.com; s=arc-20240605; b=Zp798sPaFfTMBGjtLeG2Im0gQ2JjLhdTyxK9Qn/ddjv9bSLHZPkd2vWjXbrnIUVfQq ddaAxBHkjYcrj3LnW96AKrsVpNkPY7I4ZVMuDiQ73rHdBsz1nBrlPy5oYnEv8lzwhYSt 4l7Y6DlCRwWxu0uCUqRaaksRhb7qojOzJsKbBXs5NooORHsvJCRQgsoDRi0cCanAzH1l S1GIEvMnpJ/drm6+P1zZRWhcDHS8FBndB9iP38vk0ra5RJ+XPiBKbbDrGLKi9LLNDB55 0V4cRouiXcTu/wwrWHioGfO3gWyqct2RZpEjq4rUszOLrsIzJAfetdpuxlyo5oI6LBJC Bmsw== 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=pkOgB8Knz2JhADHn2r63LFRHKq7oLg+MSv36PaYV/l8=; fh=Xa2kSlj3Lgh/jGxeTGyXy5xn0RxvRaJ8dHRZjvWIYNc=; b=K6IARZEuNDDZ10PNrClUgGte8KPGBkfuVr2InHd5oc/akpc5ISf+b2CNGKPXBNhJbj trRHp5+DFVDCE6GXrfNRocEvEnKvW+yMGJf94O0kDxJk2Lw2oobREdXCfPc6Nvjy3gCN NeLsmIpZ1VypozlkB1EHBM0ImUGYh2R+ElVsMll04NGmHmOfC6W0RkCBx/OJ/T24++1O yMOkcqXxuXLPiudcu4ZcSDOXecuWTG0rSWTFG76NM/BADeXUvOpiLRSMikCj07P7bgxT rcvnsxFq9BBomiBQ8Qk/USJfg1z/NfY4cigDAYpK0yI0iP/RqzDv2oyL0zA25zcm/K/K 8oYA==; 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=1775209205; x=1775814005; darn=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=pkOgB8Knz2JhADHn2r63LFRHKq7oLg+MSv36PaYV/l8=; b=S+LWjP2Wi6O9PeEZLkgKhxJeM9n/OPSngB65KvsiGIaJRJH2iJlBgNIvo2TJZN7eBq yh3FGqVENdsgqns+3NodjO0PvJlDtqJyb+MRNh5PoW+4SjmOAj5Im3k506LPdeGS9dl4 oiZg5cLKhoMBqltX/8l6BYSOJHTSymApD9guwwSVgFr9t/9BJPDn3qesR0L3E2gicNXC Kj7qa2zgGQihBRx5RlhpOjrcSQ89rLKqz0xKzoRLvqSG2hB27ln/B8M99LYsVkI9xW3R DoEEpg0U1+3tLzFpwGFfUIrz09KhE+Eq1VhaL3dxuVEBOxTyuFrTnC5T1DJZb47A8wPT 0KkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775209205; x=1775814005; 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=pkOgB8Knz2JhADHn2r63LFRHKq7oLg+MSv36PaYV/l8=; b=k6Yf7ZOnv66N2WHBvLW34hSmO5oTyMRzWFJ/64yn1ejm1/6vU3VKyyavDs1Fej+5Ca yLpiDqoj+vJAfYEeHT8yXw4G9sbDa5yiwH1vBMMK3XOkQCyG3QaH4zhmI16oREpaJGcC KEXiWQ2OquaXr0w59fTY6pXPLNpy+GOgLwAEpCBUdgGbSNMAK98nQxuIupfwAHaYzGH6 3bzuHXulvxthnIs2YvrApb7+NPHkGy7Aa2XuurOnUwJJiXy6yQvtu9TdZ+q801/NBC/v 8u5A4uN1ZL5F17THZE0IzR2TnXeefD0puFKRKr8iwCzJF/rT4dOm7sYdHICCtOxoxUeD 6G3Q== X-Forwarded-Encrypted: i=1; AJvYcCVCXEz6cxs+GUXuQy5V1Ozohqq/48jcxwbKHYCVJ91C57ZFfcYEil3kfINjsEE0YARgNJaFdFaBIyx04bBw@postgresql.org X-Gm-Message-State: AOJu0YwK8WMiwN0hlJLqcnz1EbmH8DvJwzV19MXxHOkd25G1YAjx/zRl 2gz4kw37tPDxvEALw9bnyusF0n3p2YKNQg/AqDTKYGXSvdasyhkrUizzo5K5JRpMfHWIXsJNs1+ Mtm6mqVSPzYYuv385bJdG5DwtYRbGHDo= X-Gm-Gg: ATEYQzzm8oS2tyLmHvYs1/BXoF3ZRdh2nputC1tI7UobAz8igCnG/Ysy2Tt54q8QuMk qa5v/AVKoTeaIesfvq5LJndJoMxEQYhj/hZ6/kxBUwAf4NlRwcXEStwjAZ+oZxNrQblzheDwMZr b3TvaxLnMWxTRZ7YFiXxFWus0djJbWvJpIZtMt0Sxx1PlwkHtJj19KsqdaW6AbXX5xxoYZpd6tQ chOpzGwczDNEBOOeCVbebyoht+Pmkv4eDX4UlR3v08b5jx/Gh2r4xH3HNxL8PfhKEE3GHY5rgwt ywgXOOde X-Received: by 2002:a05:6a20:430a:b0:39b:c9ff:e3eb with SMTP id adf61e73a8af0-39f2f045a80mr2635550637.4.1775209204956; Fri, 03 Apr 2026 02:40:04 -0700 (PDT) MIME-Version: 1.0 References: <2BE661BA-D909-4093-BF78-DB9B0C099337@gmail.com> <77FA04FE-1F84-4DA1-8855-8BBFD8CC889A@gmail.com> In-Reply-To: From: Amit Langote Date: Fri, 3 Apr 2026 18:39:48 +0900 X-Gm-Features: AQROBzBgnCTgqr-Rx80e05PsnByLk8eNFzW_xIWGh1Ogf4pwiks6L4iGLxkstsg Message-ID: Subject: Re: Eliminating SPI / SQL from some RI triggers - take 3 To: Chao Li Cc: Junwang Zhao , Haibo Yan , Pavel Stehule , PostgreSQL-development , Tomas Vondra 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 Fri, Apr 3, 2026 at 5:58=E2=80=AFPM Chao Li wro= te: > > On Apr 3, 2026, at 13:52, Amit Langote wrote: > > On Thu, Apr 2, 2026 at 5:00=E2=80=AFPM Chao Li = wrote: > >> I plan to spend time testing and tracing this patch tomorrow. But I do= n=E2=80=99t want to block your progress, if I find anything, I will report = to you. > > > > Sure, I didn't want to leave committing this to the weekend or the next= week. > > I spent several hours debugging this patch today, and I found a problem w= here the batch mode doesn't seem to handle deferred RI triggers, although t= he commit message suggests that it should. > > I traced this scenario: > ``` > CREATE TABLE pk (a int primary key); > CREATE TABLE fk (a int references pk(a) DEFERRABLE INITIALLY DEFERRED); > BEGIN; > INSERT INTO fk VALUES (1); > INSERT INTO pk VALUES (1); > COMMIT; > ``` > > When COMMIT is executed, it reaches RI_FKey_check(), where AfterTriggerIs= Active() checks whether afterTriggers.query_depth >=3D 0. But in the deferr= ed case, afterTriggers.query_depth is -1. > > From the code: > ``` > if (ri_fastpath_is_applicable(riinfo)) > { > if (AfterTriggerIsActive()) > { > /* Batched path: buffer and probe in groups */ > ri_FastPathBatchAdd(riinfo, fk_rel, newslot); > } > else > { > /* ALTER TABLE validation: per-row, no cache */ > ri_FastPathCheck(riinfo, fk_rel, newslot); > } > return PointerGetDatum(NULL); > } > ``` > > So this ends up falling back to the per-row path for deferred RI checks a= t COMMIT, even though the intent here seems to be only to bypass the ALTER = TABLE validation case, where batch callbacks would never fire, and MyTrigge= rDepth is 0. So, maybe we can just check MyTriggerDepth>0 in AfterTriggerIs= Active(). > > I tried the attached fix. With it, deferred triggers go through the batch= mode, and all existing tests still pass. I think you might be right. Thanks for the patch. It looks correct to me at a glance, but I will need to check it a bit more closely before committing. --=20 Thanks, Amit Langote