From: | Huong Dangminh <huo-dangminh(at)ys(dot)jp(dot)nec(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Hiroshi Yanagisawa <hir-yanagisawa(at)ut(dot)jp(dot)nec(dot)com> |
Subject: | RE: Re: User defined data types in Logical Replication |
Date: | 2017-11-21 15:25:08 |
Message-ID: | 75DB81BEEA95B445AE6D576A0A5C9E936A6C82E2@BPXM05GP.gisp.nec.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 | Content-Type | Size |
---|---|---|
fix_slot_store_error_callback_V2.patch | application/octet-stream | 5.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-11-21 15:29:37 | Re: Treating work_mem as a shared resource (Was: Parallel Hash take II) |
Previous Message | Tom Lane | 2017-11-21 15:16:58 | Re: Inlining functions with "expensive" parameters |