Re: "unexpected duplicate for tablespace" problem in logical replication
От | Kyotaro Horiguchi |
---|---|
Тема | Re: "unexpected duplicate for tablespace" problem in logical replication |
Дата | |
Msg-id | 20240116.105804.1924548897701268962.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: "unexpected duplicate for tablespace" problem in logical replication (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: "unexpected duplicate for tablespace" problem in logical replication
|
Список | pgsql-bugs |
At Mon, 15 Jan 2024 16:32:07 -0500, Robert Haas <robertmhaas@gmail.com> wrote in > On Fri, Jan 12, 2024 at 3:38 AM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: > > Maybe. It might be better for the cache not to register temprary > > relations at all. > > This point seems worthy of serious consideration to me. Is there any > reason why we need RelidByRelfilenumber() to work with temporary > relations at all? I understand that the current behavior is exposed > via the SQL-callable function, but maybe that's not really > intentional. If there's no other use of RelidByRelfilenumber() that > needs to care about permanent relations intrinsically, I think we > shouldn't hesitate to just cut them out of the mechanism entirely. Do you mean that the current behavior of the SQL-callable function is being treated as a bug and should it be corrected? Simply doing so will result in the functions pg_relation_filenode() and pg_filenode_relation() behaving asymmetrically. While there is no need to purposely change the behavior of the former, it is necessary to document the behavior of the latter regardless. The attached patch does the above for the master head. If we apply this approach to older versions, I can adapt and create similar patches for them. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Вложения
В списке pgsql-bugs по дате отправления: