MIME-Version: 1.0
References: <20250331212648.ad4ab804559001d7f0788741@sraoss.co.jp>
 <CAOVWO5q8cfbHiZuL-wSxknnriPCBYpqRCnQKfH38WuLwFuxkSw@mail.gmail.com>
 <20260327005646.8b9df4658b2dd510d3f95ec0@sraoss.co.jp>
 <CA+HiwqGFuhuSus8L7O36CYoeeZtGJ4PO0cR94qKDbtMKR4T2OA@mail.gmail.com>
 <20260327120057.04d16c1240fe402a3a093ada@sraoss.co.jp>
 <CA+HiwqF3RXW7BGv2PTs0Q73CJfUDseQSc=+hUsk==R64Uva87A@mail.gmail.com>
In-Reply-To: 
 <CA+HiwqF3RXW7BGv2PTs0Q73CJfUDseQSc=+hUsk==R64Uva87A@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Mon, 30 Mar 2026 10:16:02 +0900
Message-ID: 
 <CA+HiwqEhgrvnWub_iu5i6WSvYpj_ujQj3fSfDc5BQzS++j5mDA@mail.gmail.com>
Subject: Re: Add comments about fire_triggers argument in ri_triggers.c
To: Yugo Nagata <nagata@sraoss.co.jp>
Cc: surya poondla <suryapoondla4@gmail.com>, pgsql-hackers@postgresql.org,
	Kirill Reshke <reshkekirill@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BHiwqEhgrvnWub_iu5i6WSvYpj_ujQj3fSfDc5BQzS%2B%2Bj5mDA%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 27, 2026 at 2:36=E2=80=AFPM Amit Langote <amitlangote09@gmail.c=
om> wrote:
> On Fri, Mar 27, 2026 at 12:01=E2=80=AFPM Yugo Nagata <nagata@sraoss.co.jp=
> wrote:
> > On Fri, 27 Mar 2026 09:39:17 +0900
> > Amit Langote <amitlangote09@gmail.com> wrote:
> >
> > > On Fri, Mar 27, 2026 at 12:56=E2=80=AFAM Yugo Nagata <nagata@sraoss.c=
o.jp> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Thank you all for the review and comments.
> > > >
> > > > > Yes Amit, I agree that SPI_execute_snapshot() comments do provide=
 some
> > > > > context on AFTER triggers, but I still feel the newly added comme=
nt
> > > > > in ri_PerformCheck() gives additional context on why the fire_tri=
ggers is
> > > > > set to false.
> > > >
> > > > Yes, that is what I intended. The existing comments on
> > > > SPI_execute_snapshot() explain how the fire_triggers parameter work=
s,
> > > > but I would like to add a comment explaining why the AFTER trigger =
for
> > > > RI needs to set it to false.
> > > >
> > > > If the explanation of the effect of fire_triggers seems redundant, =
I am
> > > > fine with the following shorter version:
> > > >
> > > > +        * Set fire_triggers to false to ensure that check triggers=
 fire after all
> > > > +        * RI updates on the same row are complete.
> > >
> > > Thanks for the updated patch.  Yes, adding the comment might be good,
> > > but I'd suggest a small tweak:
> > >
> > > +        * Set fire_triggers to false to ensure that AFTER triggers
> > > are queued in
> > > +        * the outer query's after-trigger context and fire after all
> > > RI updates on
> > > +        * the same row are complete, rather than immediately.
> > >
> > > Two changes:
> > >
> > > * "check triggers" -> "AFTER triggers", since fire_triggers=3Dfalse
> > > affects any AFTER triggers queued during the SPI execution, not just
> > > RI check triggers.
> > >
> > > * mention of the outer query's after-trigger context to explain the
> > > mechanism by which the deferral works.
> > >
> > > Does that additional context help?
> >
> > Thank you for the suggestion.
> > That looks good to me. It is clearer than the previous version.
>
> Ok, will push the attached.

Pushed.

I verified locally with a test case involving a CASCADE DELETE on two
parent rows that the comment is indeed accurate:

CREATE TABLE parent (id int PRIMARY KEY);
CREATE TABLE child (id int REFERENCES parent ON DELETE CASCADE);
CREATE TABLE log (seq serial, msg text);

CREATE OR REPLACE FUNCTION child_after_del() RETURNS trigger AS $$
BEGIN
  INSERT INTO log(msg) VALUES ('child deleted: ' || OLD.id);
  RETURN NULL;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER "A_child_after_del_trig"
AFTER DELETE ON child
FOR EACH ROW EXECUTE FUNCTION child_after_del();
CREATE OR REPLACE FUNCTION parent_after_del() RETURNS trigger AS $$
BEGIN
  INSERT INTO log(msg) VALUES ('parent deleted: ' || OLD.id);
  RETURN NULL;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER "A_parent_after_del_trig"
AFTER DELETE ON parent
FOR EACH ROW EXECUTE FUNCTION parent_after_del();

INSERT INTO parent VALUES (1), (2);
INSERT INTO child VALUES (1), (2);
DELETE FROM parent;

SELECT msg FROM log ORDER BY seq;
        msg
-------------------
 parent deleted: 1
 parent deleted: 2
 child deleted: 1
 child deleted: 2
(4 rows)

Thanks again Nagata-san for the patch.

--=20
Thanks, Amit Langote