Re: Skipping logical replication transactions on subscriber side

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Skipping logical replication transactions on subscriber side
Date: 2021-06-01 15:35:44
Message-ID: 1f0cd48d-81b0-e8ae-df8c-f6207d00f44a@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01.06.21 06:01, Amit Kapila wrote:
> But, won't that be costly in cases where we have errors in the
> processing of very large transactions? Subscription has to process all
> the data before it gets an error. I think we can even imagine this
> feature to be extended to use commitLSN as a skip candidate in which
> case we can even avoid getting the data of that transaction from the
> publisher. So if this information is persistent, the user can even set
> the skip identifier after the restart before the publisher can send
> all the data.

At least in current practice, skipping parts of the logical replication
stream on the subscriber is a rare, emergency-level operation when
something that shouldn't have happened happened. So it doesn't really
matter how costly it is. It's not going to be more costly than the
error happening in the first place. All you'd need is one shared memory
slot per subscription to store a xid to skip.

We will also want some proper conflict handling at some point. But I
think what is being discussed here is meant to be a repair tool, not a
policy tool, and I'm afraid it might get over-engineered.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-06-01 15:56:43 Re: security_definer_search_path GUC
Previous Message Bharath Rupireddy 2021-06-01 14:55:16 Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options