Re: Truncate in synchronous logical replication failed
Ajin Cherian <itsajin@gmail.com>
From: Ajin Cherian <itsajin@gmail.com>
To: "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
Cc: Japin Li <japinli@hotmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Petr Jelinek <petr.jelinek@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, "tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-04-20T01:52:43Z
Lists: 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
Commits
-
Fix Logical Replication of Truncate in synchronous commit mode.
- e7eea52b2d61 14.0 landed
-
Logical decoding of TRUNCATE
- 5dfd1e5a6696 11.0 cited