Re: Truncate in synchronous logical replication failed

On Mon, Apr 12, 2021 at 10:03 AM osumi(dot)takamichi(at)fujitsu(dot)com
<osumi(dot)takamichi(at)fujitsu(dot)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.