Horton

RE: Truncate in synchronous logical replication failed

Yu Shi (Fujitsu) <shiy.fnst@fujitsu.com>

View thread View on postgr.es
From: "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>
To: Amit Kapila <amit.kapila16@gmail.com>, "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>
Cc: Ajin Cherian <itsajin@gmail.com>, Japin Li <japinli@hotmail.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-23T03:41:14Z
Lists: pgsql-hackers 
> I don't think here we need to restart to get a stable list of indexes
> as we do in RelationGetIndexAttrBitmap. The reason is here we build
> the cache entry using a historic snapshot and all the later changes
> are absorbed while decoding WAL. I have updated that and modified few
> comments in the attached patch. Can you please test this in
> clobber_cache_always mode? I think just testing
> subscription/t/010_truncate.pl would be sufficient.

Thanks for your patch. I tested your patch and it passes 'make check-world' and it works as expected.
By the way, I also tested in clobber_cache_always mode, it passed, too.(I only tested subscription/t/010_truncate.pl.)

Regards,
Shi yu

Commits

  1. Fix Logical Replication of Truncate in synchronous commit mode.

  2. Logical decoding of TRUNCATE