Re: Truncate in synchronous logical replication failed

Поиск
Список
Период
Сортировка
От Ajin Cherian
Тема Re: Truncate in synchronous logical replication failed
Дата
Msg-id CAFPTHDaAjR7F86MJ7eOprXMekEpV21gMSfZW_58t+c+cAOzysw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Truncate in synchronous logical replication failed  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Ответы RE: Truncate in synchronous logical replication failed
Список pgsql-hackers
Дерево обсуждения


On Sat, Apr 17, 2021 at 2:04 PM osumi.takamichi@fujitsu.com <osumi.takamichi@fujitsu.com> wrote:

No problem. Thank you for updating the patch.
I've conducted some cosmetic changes. Could you please check this ?
That's already applied by pgindent.

I executed RT for this and made no failure.
Just in case, I executed 010_truncate.pl test 100 times in a tight loop,
which also didn't fail.


I reviewed the patch, ran make check, no issues. One minor comment:

Could you add the comment similar to RelationGetIndexAttrBitmap() on why the redo, it's not very obvious
to someone reading the code, why we are refetching the index list here.

+ /* Check if we need to redo */
+ newindexoidlist = RelationGetIndexList(relation); 

thanks,
Ajin Cherian
Fujitsu Australia

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

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: Bogus collation version recording in recordMultipleDependencies
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: ANALYZE counts LP_DEAD line pointers as n_dead_tup