Re: Re: User defined data types in Logical Replication
От | Masahiko Sawada |
---|---|
Тема | Re: Re: User defined data types in Logical Replication |
Дата | |
Msg-id | CAD21AoBeDdq5BpmtU6YUb=Xj7hPZnAo3uHTVAB3ODCfDwxVwCg@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Re: User defined data types in Logical Replication (Huong Dangminh <huo-dangminh@ys.jp.nec.com>) |
Ответы |
Re: User defined data types in Logical Replication
|
Список | pgsql-hackers |
On Wed, Nov 22, 2017 at 12:25 AM, Huong Dangminh <huo-dangminh@ys.jp.nec.com> wrote: > Thanks for your response. > # And sorry again because I could not reply to your gmail > # address from my environment due to security restriction. It's okay. I can understand your environment :-) > Sorry for not replying sooner. > >> > Attached draft patch fixed this issue, at least on my environment. >> >> It works good for me. >> >> > Please review it. >> >> I will review it soon. > > There is one more case that user-defined data type is not supported in Logical Replication. > That is when remote data type's name does not exist in SUBSCRIBE. > > In relation.c:logicalrep_typmap_gettypname > We search OID in syscache by remote's data type name and mapping it, if it does not exist in syscache > We will be faced with the bellow error. > > if (!OidIsValid(entry->typoid)) > ereport(ERROR, > (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), > errmsg("data type \"%s.%s\" required for logical replication does not exist", > entry->nspname, entry->typname))); > > I think, it is not necessary to check typoid here in order to avoid above case, is that right? I think it's not right. We should end up with an error in the case where the same type name doesn't exist on subscriber. With your proposed patch, logicalrep_typmap_gettypname() can return an invalid string (entry->typname) in that case, which can be a cause of SEGV. > Sorry, I have added this thread to the next CF. Thank you for adding it. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: