RE: Re: User defined data types in Logical Replication - Mailing list pgsql-hackers

From Huong Dangminh
Subject RE: Re: User defined data types in Logical Replication
Date
Msg-id 75DB81BEEA95B445AE6D576A0A5C9E936A6C82E2@BPXM05GP.gisp.nec.co.jp
Whole thread Raw
In response to RE: Re: User defined data types in Logical Replication  (Huong Dangminh <huo-dangminh@ys.jp.nec.com>)
Responses 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  (Masahiko Sawada <sawada.mshk@gmail.com>)
List 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/


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Inlining functions with "expensive" parameters
Next
From: Robert Haas
Date:
Subject: Re: Treating work_mem as a shared resource (Was: Parallel Hash take II)