Re: Truncate in synchronous logical replication failed

> On 12 Apr 2021, at 08:58, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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).

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