On Mon, Apr 12, 2021 at 10:03 AM osumi.takami...@fujitsu.com <osumi.takami...@fujitsu.com> wrote: > > > I checked the PG-DOC, found it says that “Replication of TRUNCATE > > commands is supported”[1], so maybe TRUNCATE is not supported in > > synchronous logical replication? > > > > If my understanding is right, maybe PG-DOC can be modified like this. Any > > thought? > > Replication of TRUNCATE commands is supported > > -> > > Replication of TRUNCATE commands is supported in asynchronous mode > I'm not sure if this becomes the final solution, >
I think unless the solution is not possible or extremely complicated going via this route doesn't seem advisable. > but if we take a measure to fix the doc, we have to be careful for the > description, > because when we remove the primary keys of 'test' tables on the scenario in > [1], we don't have this issue. > It means TRUNCATE in synchronous logical replication is not always blocked. > The problem happens only when we try to fetch IDENTITY_KEY attributes because pgoutput uses RelationGetIndexAttrBitmap() to get that information which locks the required indexes. Now, because TRUNCATE has already acquired an exclusive lock on the index, it seems to create a sort of deadlock where the actual Truncate operation waits for logical replication of operation to complete and logical replication waits for actual Truncate operation to finish. Do we really need to use RelationGetIndexAttrBitmap() to build IDENTITY_KEY attributes? During decoding, we don't even lock the main relation, we just scan the system table and build that information using a historic snapshot. Can't we do something similar here? Adding Petr J. and Peter E. to know their views as this seems to be an old problem (since the decoding of Truncate operation is introduced). -- With Regards, Amit Kapila.
