Optionally automatically disable logical replication subscriptions on error - Mailing list pgsql-hackers

From Mark Dilger
Subject Optionally automatically disable logical replication subscriptions on error
Date
Msg-id DB35438F-9356-4841-89A0-412709EBD3AB@enterprisedb.com
Whole thread Raw
Responses Re: Optionally automatically disable logical replication subscriptions on error
Re: Optionally automatically disable logical replication subscriptions on error
List pgsql-hackers
Hackers,

Logical replication apply workers for a subscription can easily get stuck in an infinite loop of attempting to apply a
change,triggering an error (such as a constraint violation), exiting with an error written to the subscription worker
log,and restarting. 

As things currently stand, only superusers can create subscriptions.  Ongoing work to delegate superuser tasks to
non-superuserscreates the potential for even more errors to be triggered, specifically, errors where the apply worker
doesnot have permission to make changes to the target table. 

The attached patch makes it possible to create a subscription using a new subscription_parameter, "disable_on_error",
suchthat rather than going into an infinite loop, the apply worker will catch errors and automatically disable the
subscription,breaking the loop.  The new parameter defaults to false.  When false, the PG_TRY/PG_CATCH overhead is
avoided,so for subscriptions which do not use the feature, there shouldn't be any change.  Users can manually clear the
errorafter fixing the underlying issue with an ALTER SUBSCRIPTION .. ENABLE command.  

In addition to helping on production systems, this makes writing TAP tests involving error conditions simpler.  I
originallyran into the motivation to write this patch when frustrated that TAP tests needed to parse the apply worker
logfile to determine whether permission failures were occurring and what they were.  It was also obnoxiously easy to
havea test get stuck waiting for a permanently stuck subscription to catch up.  This helps with both issues. 

I don't think this is quite ready for commit, but I'd like feedback if folks like this idea or want to suggest design
changes.



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




Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Centralizing protective copying of utility statements
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench logging broken by time logic changes