Re: [BUG] "FailedAssertion" reported when streaming in logical replication

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [BUG] "FailedAssertion" reported when streaming in logical replication
Дата
Msg-id CAFiTN-uqnnDxzo5Z2HWrcXr-QUBNZF_zejuH4ZqTWVFMV4vZPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUG] "FailedAssertion" reported when streaming in logical replication  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Mon, Apr 26, 2021 at 7:52 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Mon, Apr 26, 2021 at 6:59 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Apr 26, 2021 at 5:55 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >
> > > I am able to reproduce this and I think I have done the initial investigation.
> > >
> > > The cause of the issue is that, this transaction has only one change
> > > and that change is XLOG_HEAP2_NEW_CID, which is added through
> > > SnapBuildProcessNewCid.  Basically, when we add any changes through
> > > SnapBuildProcessChange we set the base snapshot but when we add
> > > SnapBuildProcessNewCid this we don't set the base snapshot, because
> > > there is nothing to be done for this change.  Now, this transaction is
> > > identified as the biggest transaction with non -partial changes, and
> > > now in ReorderBufferStreamTXN, it will return immediately because the
> > > base_snapshot is NULL.
> > >
> >
> > Your analysis sounds correct to me.
> >
>
> Thanks, I have attached a patch to fix this.

There is also one very silly mistake in below condition, basically,
once we got any transaction for next transaction it is unconditionally
selecting without comparing the size because largest != NULL is wrong,
ideally this should be largest == NULL, basically, if we haven't
select any transaction then only we can approve next transaction
without comparing the size.

if ((largest != NULL || txn->total_size > largest_size) &&
(txn->base_snapshot != NULL) && (txn->total_size > 0) &&
!(rbtxn_has_incomplete_tuple(txn)))


-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: Replication slot stats misgivings
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Performance degradation of REFRESH MATERIALIZED VIEW