RE: Truncate in synchronous logical replication failed

On Tuesday, April 13, 2021 11:38 PM Petr Jelinek <petr.jelinek@enterprisedb.com> wrote:
> > On 12 Apr 2021, at 08:58, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Mon, Apr 12, 2021 at 10:03 AM osumi.takamichi@fujitsu.com
> > <osumi.takamichi@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.
This was true.

Having a look at the comment of index_open(), there's a description of basic rule
that NoLock should be used if appropriate lock on the index is already taken.
And, making the walsender use NoLock to build the attributes
leads us to the Assert in the relation_open().

Please ignore the two ideas I suggested in another mail,
which doesn't follow the basic and work.

Best Regards,
    Takamichi Osumi