Re: Skipping logical replication transactions on subscriber side
От | Amit Kapila |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAA4eK1+DDLOHNJWTWy-fsO8hK4E1dFvDhrKrfgW5kRUjo=Uenw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Skipping logical replication transactions on subscriber side (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Skipping logical replication transactions on subscriber side
|
Список | pgsql-hackers |
On Fri, Feb 11, 2022 at 7:40 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Thu, Jan 27, 2022 at 10:42 PM Peter Eisentraut > <peter.eisentraut@enterprisedb.com> wrote: > > > > On 26.01.22 05:05, Masahiko Sawada wrote: > > >> I think it is okay to clear after the first successful application of > > >> any transaction. What I was not sure was about the idea of giving > > >> WARNING/ERROR if the first xact to be applied is not the same as > > >> skip_xid. > > > Do you prefer not to do anything in this case? > > > > I think a warning would be sensible. If the user specifies to skip a > > certain transaction and then that doesn't happen, we should at least say > > something. > > Meanwhile waiting for comments on the discussion about the designs of > both pg_stat_subscription_workers and ALTER SUBSCRIPTION SKIP feature, > I’ve incorporated some (minor) comments on the current design patch, > which includes: > > * Use LSN instead of XID. > I think exposing LSN is a better approach as it doesn't have the dangers of wraparound. And, I think users can use it with the existing function pg_replication_origin_advance() which will save us from adding additional code for this feature. We can explain/expand in docs how users can use the error information from view/error_logs and use the existing function to skip conflicting transactions. We might want to even expose error_origin to make it a bit easier for users but not sure. I feel the need for the new syntax (and then added code complexity due to that) isn't warranted if we expose error_LSN and let users use it with the existing functions. Do you see any problem with the same? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: