RE: Re: User defined data types in Logical Replication

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

In response to

Responses

Browse pgsql-hackers by date

  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