From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Greg Nancarrow <gregn4422(at)gmail(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, Alexey Lesovsky <lesovsky(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Skipping logical replication transactions on subscriber side |
Date: | 2021-12-14 06:10:38 |
Message-ID: | CAFiTN-u=GOUZ_Sg20ZeMmWfHh9qppbHQrD1ViFPVS8HPqYCD5Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 3, 2021 at 12:12 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> Skipping a whole transaction by specifying xid would be a good start.
> Ideally, we'd like to automatically skip only operations within the
> transaction that fail but it seems not easy to achieve. If we allow
> specifying operations and/or relations, probably multiple operations
> or relations need to be specified in some cases. Otherwise, the
> subscriber cannot continue logical replication if the transaction has
> multiple operations on different relations that fail. But similar to
> the idea of specifying multiple xids, we need to note the fact that
> user wouldn't know of the second operation failure unless the apply
> worker applies the change. So I'm not sure there are many use cases in
> practice where users can specify multiple operations and relations in
> order to skip applies that fail.
I think there would be use cases for specifying the relations or
operation, e.g. if the user finds an issue in inserting in a
particular relation then maybe based on some manual investigation he
founds that the table has some constraint due to that it is failing on
the subscriber side but on the publisher side that constraint is not
there so maybe the user is okay to skip the changes for this table and
not for other tables, or there might be a few more tables which are
designed based on the same principle and can have similar error so
isn't it good to provide an option to give the list of all such
tables.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-12-14 06:14:49 | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |
Previous Message | Greg Nancarrow | 2021-12-14 05:35:38 | Re: Skipping logical replication transactions on subscriber side |