public inbox for [email protected]  

help / color / mirror / Atom feed

From: Mark Dilger <[email protected]>
To: Amit Kapila <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Smith, Peter <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Optionally automatically disable logical replication subscriptions on error
Date: Sun, 20 Jun 2021 22:12:44 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1+NoRbYSH1J08zi4OJ_EUMcjmxTwnmwVqZ6e_xzS0D6VA@mail.gmail.com>
References: <[email protected]>
	<CAA4eK1KkhsNAW3=XxOdVRD9+RcQG5PRRFBFzAMibMG0YFFmAmg@mail.gmail.com>
	<[email protected]>
	<CAA4eK1KM23D06_rUEsgnTFUpABoeCCoTun2TMrQzWgxWOYY7fA@mail.gmail.com>
	<[email protected]>
	<CAD21AoB+QH4or-QDiakALZp6pkXiAaGxfGcsvNYJoDHk9kknZw@mail.gmail.com>
	<[email protected]>
	<CAA4eK1+NoRbYSH1J08zi4OJ_EUMcjmxTwnmwVqZ6e_xzS0D6VA@mail.gmail.com>



> On Jun 20, 2021, at 8:09 PM, Amit Kapila <[email protected]> wrote:
> 
> (a) to define exactly what all
> information is required to be logged on error, (b) where do we want to
> store the information based on requirements.

I'm not sure it has to be stored anywhere durable.  I have a patch in the works to do something like:

create function foreign_key_insert_violation_before() returns conflict_trigger as $$
BEGIN
    RAISE NOTICE 'elevel: %', TG_ELEVEL:
    RAISE NOTICE 'sqlerrcode: %', TG_SQLERRCODE:
    RAISE NOTICE 'message: %', TG_MESSAGE:
    RAISE NOTICE 'detail: %', TG_DETAIL:
    RAISE NOTICE 'detail_log: %', TG_DETAIL_LOG:
    RAISE NOTICE 'hint: %', TG_HINT:
    RAISE NOTICE 'schema: %', TG_SCHEMA_NAME:
    RAISE NOTICE 'table: %', TG_TABLE_NAME:
    RAISE NOTICE 'column: %', TG_COLUMN_NAME:
    RAISE NOTICE 'datatype: %', TG_DATATYPE_NAME:
    RAISE NOTICE 'constraint: %', TG_CONSTRAINT_NAME:

        -- do something useful to prepare for retry of transaction
        -- which raised a foreign key violation
END
$$ language plpgsql;

create function foreign_key_insert_violation_after() returns conflict_trigger as $$
BEGIN
        -- do something useful to cleanup after retry of transaction
        -- which raised a foreign key violation
END
$$ language plpgsql;

create conflict trigger regress_conflict_trigger_insert on regress_conflictsub
   before foreign_key_violation
   when tag in ('INSERT')
   execute procedure foreign_key_insert_violation_before();

create conflict trigger regress_conflict_trigger_insert on regress_conflictsub
   after foreign_key_violation
   when tag in ('INSERT')
   execute procedure foreign_key_insert_violation_after();

The idea is that, for subscriptions that have conflict triggers defined, the apply will be wrapped in a PG_TRY()/PG_CATCH() block.  If it fails, the ErrorData will be copied in the ConflictTriggerContext, and then the transaction will be attempted again, but this time with any BEFORE and AFTER triggers applied.  The triggers could then return a special result indicating whether the transaction should be permanently skipped, applied, or whatever.  None of the data needs to be stored anywhere non-transient, as it just gets handed to the triggers.

I think the other patch is a subset of this functionality, as using this system to create triggers which query a table containing transactions to be skipped would be enough to get the functionality you've been discussing.  But this system could also do other things, like modify data.  Admittedly, this is akin to a statement level trigger and not a row level trigger, so a number of things you might want to do would be hard to do from this.  But perhaps the equivalent of row level triggers could also be written?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

view thread (74+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Optionally automatically disable logical replication subscriptions on error
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox