On Thu, Dec 9, 2021 at 2:24 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Thu, Dec 9, 2021 at 11:47 AM Amit Kapila <amit.kapil...@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.