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 CAA4eK1KFxwbMm+Jfdmy=t3VWvpyOvFffNzOZhrvDD_ZHAM=dwQ@mail.gmail.com
Whole thread Raw
In response to Re: Forget close an open relation in ReorderBufferProcessTXN()  (Andres Freund <andres@anarazel.de>)
Responses Re: Forget close an open relation in ReorderBufferProcessTXN()  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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"?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Forget close an open relation in ReorderBufferProcessTXN()
Next
From: Japin Li
Date:
Subject: Re: Forget close an open relation in ReorderBufferProcessTXN()