Re: BUG #18019: misbehaviour by replication

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: a(dot)kutepow(at)prodat-sql(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18019: misbehaviour by replication
Date: 2023-07-13 07:49:01
Message-ID: 20230713.164901.624326636983516094.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At Wed, 12 Jul 2023 10:08:54 +0000, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote in
(In short, foreign constraint trigger doesn't fire on apply woker.)
> this is (imho) misbehaviour!
> replication should not break integrity and break references logic!
> or explain why it's right and how to live with it?

You can activate the fkey constraints on the subscriber by setting the
underlying triggers to ENABLE ALWAYS (or REPLICA) using the ALTER
TABLE command.

By design, triggers are not active on subscribers by default. It might
seem peculiar, especially in the context of foreign key constraints,
as check constraints are operational on subscribers. Moreover,
although the documentation mentions that the purpose of the behavior
is avoid propagating data between tables again on subscribers, foreign
key triggers don't contribute to this.

If we're willing to enable constraint triggers on subscribers by
default, CreateTrigger can choose trigger_fires_when passed to
CreateTriggerFiringOn based on constraintOid. However, I'm unceratin
about the case of CREATE CONSTRAINT TRIGGER.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
fkey_eanble_on_subscribers.diff text/x-patch 617 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2023-07-13 08:21:34 RE: BUG #18019: misbehaviour by replication
Previous Message Michael Paquier 2023-07-13 06:58:56 Re: The same 2PC data maybe recovered twice