Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE
Дата
Msg-id CA+hUKGKRwSadbxnQfaj2Mtra2bwXS+nOo89J+mKViGhF2RVnAw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jun 22, 2021 at 10:01 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Jun 22, 2021 at 10:33 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> > While scanning for assertion failures on the build farm that don't
> > appear to have been discussed, I found this[1] in
> > 010_truncate_publisher.log on the 13 branch:
> >
> > TRAP: FailedAssertion("tupdesc->tdrefcount <= 0", File:
> > "/home/bf/build/buildfarm-desmoxytes/REL_13_STABLE/pgsql.build/../pgsql/src/backend/access/common/tupdesc.c",
> > Line: 321)
>
> I guess this could be similar to what we see at:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2021-06-15%2020%3A49%3A26
>
> We have discussed this in another thread at:
> https://www.postgresql.org/message-id/648020.1623854904%40sss.pgh.pa.us
>
> The reason why I think it is the same is that assertion failure shown
> in the report is from function FreeTupleDesc() which we can call from
> pgoutput.c while processing the invalidation. Ideally, we shouldn't
> call invalidation before initializing the tuple conversion map for
> partitions but in some rare cases, that was happening which we have
> fixed in commit
> (https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=357cb8f07f95665ea533ff534821c22c35b01288).
>
> I see this report is from 16th June 2021 and the commit is on 18th
> June 2021. So, I am hoping this should have been fixed but if we see
> it again then probably we need to investigate it further.

Ahh, that makes sense.  Thanks for checking, and sorry for the noise.



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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench logging broken by time logic changes
Следующее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: [bug?] Missed parallel safety checks, and wrong parallel safety