On Mon, Apr 4, 2022 at 11:42 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Sat, Apr 2, 2022 at 8:52 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
>
> It's not related to this issue but I think that non-transactional
> sequence changes could be resent in case of the subscriber crashes
> because it doesn’t update replication origin LSN, is that right? If
> so, while resending the sequence changes, the sequence value on the
> subscriber can temporarily go backward.
>
Yes, this can happen for the non-transactional sequence changes though
this is a different problem than what is happening on the decoding
side.
> > >> Also, there's the bug with decoding changes in transactions that create
> > >> the sequence and add it to a publication. I think the agreement was that
> > >> this behavior was incorrect, we should not decode changes until the
> > >> subscription is refreshed. Doesn't that mean can't be any CREATE case,
> > >> just ALTER?
> > >>
> > >
> > > Yeah, but how will we distinguish them. Aren't they using the same
> > > kind of WAL record?
> > >
> >
> > Same WAL record, but the "created" flag which should distinguish these
> > two cases, IIRC.
>
> Since the "created" flag indicates that we created a new relfilenode
> so it's true when both CREATE and ALTER.
>
Yes, this is my understanding as well. So, we need something else.
--
With Regards,
Amit Kapila.
