RE: Truncate in synchronous logical replication failed

Поиск
Список
Период
Сортировка
От osumi.takamichi@fujitsu.com
Тема RE: Truncate in synchronous logical replication failed
Дата
Msg-id OSBPR01MB48880D065ECAF8BC1C2A54D6ED489@OSBPR01MB4888.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Truncate in synchronous logical replication failed  (Ajin Cherian <itsajin@gmail.com>)
Ответы Re: Truncate in synchronous logical replication failed
Список pgsql-hackers
On  Tuesday, April 20, 2021 10:53 AM Ajin Cherian <itsajin@gmail.com> wrote:
> On Sat, Apr 17, 2021 at 2:04 PM osumi.takamichi@fujitsu.com
> <mailto:osumi.takamichi@fujitsu.com>  <osumi.takamichi@fujitsu.com
> <mailto: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 <http://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);
Yeah, makes sense. Fixed.
Its indents seem a bit weird but came from pgindent.
Thank you for your review !


Best Regards,
    Takamichi Osumi


Вложения

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

Предыдущее
От: "wangw.fnst@fujitsu.com"
Дата:
Сообщение: An omission of automatic completion in tab-complete.c
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: 2 questions about volatile attribute of pg_proc.