On Sat, Apr 17, 2021 at 12:01 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Apr 16, 2021 at 11:24 PM Andres Freund <andres@anarazel.de> wrote:
> >
> >
> > > I think it is also important to *not* acquire any lock on relation
> > > otherwise it can lead to some sort of deadlock or infinite wait in the
> > > decoding process. Consider a case for operations like Truncate (or if
> > > the user has acquired an exclusive lock on the relation in some other
> > > way say via Lock command) which acquires an exclusive lock on
> > > relation, it won't get replicated in synchronous mode (when
> > > synchronous_standby_name is configured). The truncate operation will
> > > wait for the transaction to be replicated to the subscriber and the
> > > decoding process will wait for the Truncate operation to finish.
> >
> > However, this cannot be really relied upon for catalog tables. An output
> > function might acquire locks or such. But for those we do not need to
> > decode contents...
> >
>
> I see that if we define a user_catalog_table (create table t1_cat(c1
> int) WITH(user_catalog_table = true);), we are able to decode
> operations like (insert, truncate) on such a table. What do you mean
> by "But for those we do not need to decode contents"?
>
I think we are allowed to decode the operations on user catalog tables
because we are using RelationIsLogicallyLogged() instead of
RelationIsAccessibleInLogicalDecoding() in ReorderBufferProcessTXN().
Based on this discussion, I think we should not be allowing decoding
of operations on user catalog tables, so we should use
RelationIsAccessibleInLogicalDecoding to skip such ops in
ReorderBufferProcessTXN(). Am, I missing something?
Can you please clarify?
--
With Regards,
Amit Kapila.
