Re: Forget close an open relation in ReorderBufferProcessTXN()

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Forget close an open relation in ReorderBufferProcessTXN()
Дата
Msg-id CAA4eK1LP8xTysPEMEBYAZ=6KoMWfjyf0gzF-9Bp=SgVFvYQDVw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Forget close an open relation in ReorderBufferProcessTXN()  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Ответы RE: Forget close an open relation in ReorderBufferProcessTXN()
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Unresolved repliaction hang and stop problem.
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Replication slot stats misgivings