RE: Re: User defined data types in Logical Replication

Поиск
Список
Период
Сортировка
От Huong Dangminh
Тема RE: Re: User defined data types in Logical Replication
Дата
Msg-id 75DB81BEEA95B445AE6D576A0A5C9E936A6C82E2@BPXM05GP.gisp.nec.co.jp
обсуждение исходный текст
Ответ на RE: Re: User defined data types in Logical Replication  (Huong Dangminh <huo-dangminh@ys.jp.nec.com>)
Ответы RE: Re: User defined data types in Logical Replication
Re: Re: User defined data types in Logical Replication
Список pgsql-hackers
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 attached a patch based on Sawada-san's patch with a bit of messages modified and remove the above check.
Could somebody check it for me or should I add it into CF?


---
Thanks and best regards,
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Inlining functions with "expensive" parameters
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)