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

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:
> >
> > On Saturday, April 17, 2021 4:13 PM Amit Kapila
> <amit.kapila16@gmail.com> wrote:
> > > > I also don't find a test for this.  It is introduced in
> > > > 5dfd1e5a6696, wrote by Simon Riggs, Marco Nenciarini and Peter
> > > > Eisentraut.  Maybe they can explain when we can enter this condition?
> > >
> > > My guess is that this has been copied from the code a few lines
> > > above to handle insert/update/delete where it is required to handle
> > > some DDL ops like Alter Table but I think we don't need it here (for
> > > Truncate op). If that understanding turns out to be true then we
> > > should either have an Assert for this or an elog message.
> > In this thread, we are discussing 3 topics below...
> >
> > (1) necessity of the check for REORDER_BUFFER_CHANGE_TRUNCATE
> in
> > ReorderBufferProcessTXN()
> > (2) discussion of whether we disallow decoding of operations on user
> > catalog tables or not
> > (3) memory leak of maybe_send_schema() (patch already provided)
> >
> > Let's address those one by one.
> > In terms of (1), which was close to the motivation of this thread,
> >
> 
> I think (1) and (2) are related because if we need (2) then the check removed
> by (1) needs to be replaced with another check. So, I am not sure how to
> make this decision.
Yeah, you are right.


On Monday, April 19, 2021 9:23 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> 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?
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 ?


[1] - https://www.postgresql.org/message-id/flat/20130914204913.GA4071%40awork2.anarazel.de

Note that in this discussion, user_catalog_table was renamed from
treat_as_catalog_table in the middle of the thread. Searching it might help you to shorten your time to have a look at
it.

[2] - https://www.postgresql.org/message-id/CA%2BTgmobhDCHuckL_86wRDWJ31Gw3Y1HrQ4yUKEn7U1_hTbeVqQ%40mail.gmail.com


Best Regards,
    Takamichi Osumi