> On 12 Apr 2021, at 08:58, Amit Kapila <amit.kapil...@gmail.com> wrote: > > 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).
We used RelationGetIndexAttrBitmap because it already existed, no other reason. I am not sure what exact locking we need but I would have guessed at least AccessShareLock would be needed. -- Petr
