Re: Add comments about fire_triggers argument in ri_triggers.c

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: surya poondla <suryapoondla4(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Kirill Reshke <reshkekirill(at)gmail(dot)com>
Subject: Re: Add comments about fire_triggers argument in ri_triggers.c
Date: 2026-03-27 03:00:57
Message-ID: 20260327120057.04d16c1240fe402a3a093ada@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 27 Mar 2026 09:39:17 +0900
Amit Langote <amitlangote09(at)gmail(dot)com> wrote:

> On Fri, Mar 27, 2026 at 12:56 AM Yugo Nagata <nagata(at)sraoss(dot)co(dot)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 comment
> > > in ri_PerformCheck() gives additional context on why the fire_triggers is
> > > set to false.
> >
> > Yes, that is what I intended. The existing comments on
> > SPI_execute_snapshot() explain how the fire_triggers parameter works,
> > 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=false
> 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.

Regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2026-03-27 03:16:29 RE: Initial COPY of Logical Replication is too slow
Previous Message Michael Paquier 2026-03-27 02:59:33 Re: [Proposal] pg_stat_wal_records – per-record-type WAL generation statistics