On Wed, Jan 12, 2022 at 5:49 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Tue, Jan 11, 2022 at 7:08 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Tue, Jan 11, 2022 at 1:51 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > On second thought, the same is true for other cases, for example,
> > > preparing the transaction and clearing skip_xid while handling a
> > > prepare message. That is, currently we don't clear skip_xid while
> > > handling a prepare message but do that while handling commit/rollback
> > > prepared message, in order to avoid the worst case. If we do both
> > > while handling a prepare message and the server crashes between them,
> > > it ends up that skip_xid is cleared and the transaction will be
> > > resent, which is identical to the worst-case above.
> > >
> >
> > How are you thinking to update the skip xid before prepare? If we do
> > it in the same transaction then the changes in the catalog will be
> > part of the prepared xact but won't be committed. Now, say if we do it
> > after prepare, then the situation won't be the same because after
> > restart the same xact won't appear again.
>
> I was thinking to commit the catalog change first in a separate
> transaction while not updating origin LSN and then prepare an empty
> transaction while updating origin LSN.
>
But, won't it complicate the handling if in the future we try to
enhance this API such that it skips partial changes like skipping only
for particular relation(s) or particular operations as discussed
previously in this thread?
--
With Regards,
Amit Kapila.
