Re: Skipping logical replication transactions on subscriber side
От | Masahiko Sawada |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAD21AoBwb-BCKK=a=2zphqi7d6LEJA3YkdZg3LxUeS+v13Htaw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, Oct 19, 2021 at 12:38 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Oct 19, 2021 at 8:23 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Mon, Oct 18, 2021 at 6:07 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > On Mon, Oct 11, 2021 at 1:00 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > > > On Sun, Oct 10, 2021 at 11:04 PM Peter Eisentraut > > > > <peter.eisentraut@enterprisedb.com> wrote: > > > > > > > > > > On 04.10.21 02:31, Masahiko Sawada wrote: > > > > > > I guess disabling subscriptions on error/conflict and skipping the > > > > > > particular transactions are somewhat different types of functions. > > > > > > Disabling subscriptions on error/conflict seems likes a setting > > > > > > parameter of subscriptions. The users might want to specify this > > > > > > option at creation time. Whereas, skipping the particular transaction > > > > > > is a repair function that the user might want to use on the spot in > > > > > > case of a failure. I’m concerned a bit that combining these functions > > > > > > to one syntax could confuse the users. > > > > > > > > > > Also, would the skip option be dumped and restored using pg_dump? Maybe > > > > > there is an argument for yes, but if not, then we probably need a > > > > > different path of handling it separate from the more permanent options. > > > > > > > > Good point. I don’t think the skip option should be dumped and > > > > restored using pg_dump since the utilization of transaction ids in > > > > another installation is different. > > > > > > > > > > This is a xid of publisher which subscriber wants to skip. So, even if > > > one restores the subscriber data in a different installation why would > > > it matter till it points to the same publisher? > > > > > > Either way, can't we handle this in pg_dump? > > > > Because of backups (dumps), I think we cannot expect that the user > > restore it somewhere soon. If the dump is restored several months > > later, the publisher could be a different installation (by rebuilding > > from scratch) or XID of the publisher could already be wrapped around. > > It might be useful to dump the skip_xid by pg_dump in some cases, but > > I think it should be optional if we want to do that. > > > > Agreed, I think it depends on the use case, so we can keep it > optional, or maybe in the initial version let's not dump it, and only > if we later see the use case then we can add an optional parameter in > pg_dump. Agreed. I prefer not to dump it in the first version since it's difficult to remove the option once it's introduced. > Do you think we need any special handling if we decide not to > dump it? I think if we decide to dump it either optionally or > otherwise, then we do need changes in pg_dump. Yeah, if we don't dump the skip_xid (which is the current patch behavior), any special handling is not required for pg_dump. On the other hand, if we do that in any way, we need changes for pg_dump. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
В списке pgsql-hackers по дате отправления:
Следующее
От: "tanghy.fnst@fujitsu.com"Дата:
Сообщение: RE: Added schema level support for publication.