On Mon, Apr 4, 2022 at 11:42 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Sat, Apr 2, 2022 at 8:52 PM Tomas Vondra > <tomas.von...@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.
