On 5/7/19 7:42 μ.μ., Peter Eisentraut wrote:
> On 2019-07-05 12:17, Achilleas Mantzios wrote:
>> we run some replication statements code under with session_replication_role TO 'replica' ,
>> however this disables FK constraints and consequently some important ON DELETE CASCADE that must be run.
>>
>> I tested this and this works :
>> psql -qt -c 'SELECT '\''ALTER TABLE mariner ENABLE ALWAYS TRIGGER "'\''|| tgname||'\''";'\'' from pg_trigger where
tgconstrname='\''personal_email_sender_marinerid_fkey'\''and tgisconstraint and
>> tgrelid='\''mariner'\''::regclass' | psql -f -
>>
>> and then test with:
>> BEGIN ;
>> set session_replication_role TO 'replica';
>> DELETE FROM mariner where id = 23700;
>> SELECT * from personal_email_sender where marinerid = 23700;
>> email | marinerid
>> -------+-----------
>> (0 rows)
>>
>> ^^^ and verify that the ON DELETE CASCADE is run.
>>
>> So, besides the obvious comment, that one should not mess with system triggers, do you see any potential gotcha with
thisparticular one?
> I think this is generally OK.
>
> But if you are doing this, you probably have a replication system that
> is running under the replica session role. The question is then whether
> that replication system is OK with it. If you create replication sets
> that contain parts of foreign key relationships and not others then you
> might run into constraint violations.
Thank you Peter. This is based on DBMIrror, I am running a heavily changed version of it for over 15 years, the FK
aspectwas one of the initial concerns dealt by the code. The whole idea behind it
was to satisfy FK dependencies in a minimalistic manner : include only those FK rows that are necessary.
>
--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt