Re: Skipping logical replication transactions on subscriber side - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Skipping logical replication transactions on subscriber side
Date
Msg-id CAD21AoBh_fRr=pEn6gdazqRVYA5VGXWt4mgmcuFK3iQB8KuTBg@mail.gmail.com
Whole thread Raw
In response to Re: Skipping logical replication transactions on subscriber side  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Skipping logical replication transactions on subscriber side
Re: Skipping logical replication transactions on subscriber side
List pgsql-hackers
On Fri, Oct 1, 2021 at 5:05 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 30.09.21 07:45, Masahiko Sawada wrote:
> > I've attached updated patches that incorporate all comments I got so
> > far. Please review them.
>
> I'm uneasy about the way the xids-to-be-skipped are presented as
> subscriptions options, similar to settings such as "binary".  I see how
> that is convenient, but it's not really the same thing, in how you use
> it, is it?  Even if we share some details internally, I feel that there
> should be a separate syntax somehow.

Since I was thinking that ALTER SUBSCRIPTION ... SET is used to alter
parameters originally set by CREATE SUBSCRIPTION, in the first several
version patches it added a separate syntax for this feature like ALTER
SUBSCRIPTION ... SET SKIP TRANSACTION xxx. But Amit was concerned
about an additional syntax and consistency with disable_on_error[1]
which is proposed by Mark Diliger[2], so I’ve changed it to a
subscription option. I tried to find a policy of that by checking the
existing syntaxes but I could not find, and interestingly when it
comes to ALTER SUBSCRIPTION syntax, we support both ENABLE/DISABLE
syntax and SET (enabled = on/off) option.

> Also, what happens when you forget to reset the xid after it has passed?
>   Will it get skipped again after wraparound?

Yes. Currently it's a user's responsibility. We thoroughly documented
the risk of this feature and thus it should be used as a last resort
since it may easily make the subscriber inconsistent, especially if a
user specifies the wrong transaction ID.

Regards,

[1] https://www.postgresql.org/message-id/CAA4eK1LjrU8x%2Bx%3DbFazVD10pgOVy0PEE8mpz3nQhDG%2BmmU8ivQ%40mail.gmail.com
[2] https://www.postgresql.org/message-id/DB35438F-9356-4841-89A0-412709EBD3AB%40enterprisedb.com

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Record a Bitmapset of non-pruned partitions
Next
From: Masahiko Sawada
Date:
Subject: Re: Diagnostic comment in LogicalIncreaseXminForSlot