Postgres Pro
Downloads
Home   >   mailing lists

Re: Truncate in synchronous logical replication failed - Mailing list pgsql-hackers

From Ajin Cherian
Subject Re: Truncate in synchronous logical replication failed
Date
Msg-id CAFPTHDaAjR7F86MJ7eOprXMekEpV21gMSfZW_58t+c+cAOzysw@mail.gmail.com
Whole thread Raw
In response to RE: Truncate in synchronous logical replication failed  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses RE: Truncate in synchronous logical replication failed  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
List pgsql-hackers
Tree view


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 by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Bogus collation version recording in recordMultipleDependencies
Next
From: Peter Geoghegan
Date:
Subject: Re: ANALYZE counts LP_DEAD line pointers as n_dead_tup