Re: Forget close an open relation in ReorderBufferProcessTXN() - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Forget close an open relation in ReorderBufferProcessTXN()
Date
Msg-id CAA4eK1LP8xTysPEMEBYAZ=6KoMWfjyf0gzF-9Bp=SgVFvYQDVw@mail.gmail.com
Whole thread Raw
In response to RE: Forget close an open relation in ReorderBufferProcessTXN()  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Responses RE: Forget close an open relation in ReorderBufferProcessTXN()  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
List pgsql-hackers
On Wed, Apr 28, 2021 at 5:36 PM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Monday, April 26, 2021 2:05 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Fri, Apr 23, 2021 at 8:03 PM osumi.takamichi@fujitsu.com
> > <osumi.takamichi@fujitsu.com> wrote:
> > 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?
> I don't understand that point, either.
>
> I read the context where the user_catalog_table was introduced - [1].
> There, I couldn't find any discussion if we should skip decode operations
> on that kind of tables or not. Accordingly, we just did not conclude it, I suppose.
>
> What surprised me a bit is to decode operations of system catalog table are considered like [2]
> somehow at the time. I cannot find any concrete description of such use cases in the thread, though.
>
> Anyway, I felt disallowing decoding of operations on user catalog tables
> doesn't spoil the feature's purpose. So, I'm OK to do so. What do you think ?
>

I am not so sure about it because I think we don't have any example of
user_catalog_tables in the core code. This is the reason I was kind of
looking towards Andres to clarify this. Right now, if the user
performs TRUNCATE on user_catalog_table in synchronous mode then it
will hang in case the decoding plugin takes even share lock on it. The
main reason is that we allow decoding of TRUNCATE operation for
user_catalog_tables. I think even if we want to allow decoding of
other operations on user_catalog_table, the decoding of TRUNCATE
should be prohibited but maybe we shouldn't allow decoding of any
operation on such tables as we don't do it for system catalog tables.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Unresolved repliaction hang and stop problem.
Next
From: Masahiko Sawada
Date:
Subject: Re: Replication slot stats misgivings