Обсуждение: pgsql 8.3 : force FK (and consequently ON DELETE CASCADE) to be rununder session_replication_role TO 'replica'

Hello,
first off, don't be put off by the version (8.3), please!
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?
 

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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