Re: Forget close an open relation in ReorderBufferProcessTXN()
От | Amit Kapila |
---|---|
Тема | Re: Forget close an open relation in ReorderBufferProcessTXN() |
Дата | |
Msg-id | CAA4eK1KFxwbMm+Jfdmy=t3VWvpyOvFffNzOZhrvDD_ZHAM=dwQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Forget close an open relation in ReorderBufferProcessTXN() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Forget close an open relation in ReorderBufferProcessTXN()
|
Список | 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 по дате отправления: