Re: Skipping logical replication transactions on subscriber side
От | Amit Kapila |
---|---|
Тема | Re: Skipping logical replication transactions on subscriber side |
Дата | |
Msg-id | CAA4eK1La0Oum41L9=bgdU6AjJXY7TvPXEWhgm+sKtdg3JCY27w@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 Thu, Dec 9, 2021 at 2:24 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Thu, Dec 9, 2021 at 11:47 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > I am thinking that we can start a transaction, update the catalog, > > commit that transaction. Then start a new one to update > > origin_lsn/timestamp, finishprepared, and commit it. Now, if it > > crashes after the first transaction, only commit prepared will be > > resent again and this time we don't need to update the catalog as that > > entry would be already cleared. > > Sounds good. In the crash case, it should be fine since we will just > commit an empty transaction. The same is true for the case where > skip_xid has been changed after skipping and preparing the transaction > and before handling commit_prepared. > > Regarding the case where the user specifies XID of the transaction > after it is prepared on the subscriber (i.g., the transaction is not > empty), we won’t skip committing the prepared transaction. But I think > that we don't need to support skipping already-prepared transaction > since such transaction doesn't conflict with anything regardless of > having changed or not. > Yeah, this makes sense to me. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: