Re: User defined data types in Logical Replication

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Huong Dangminh <huo-dangminh(at)ys(dot)jp(dot)nec(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Hiroshi Yanagisawa <hir-yanagisawa(at)ut(dot)jp(dot)nec(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Subject: Re: User defined data types in Logical Replication
Date: 2018-03-06 17:52:21
Message-ID: 20180306175221.3wife6tcrltwvqyj@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Masahiko Sawada wrote:
> On Tue, Mar 6, 2018 at 8:35 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:

> > Therefore, I'm inclined to make this function raise a warning, then
> > return a substitute value (something like "unrecognized type XYZ").
> > [...]
> I agree with you about not hiding the actual reason for the error but
> if we raise a warning at logicalrep_typmap_gettypname don't we call
> slot_store_error_callback recursively?

Hmm, now that you mention it, I don't really know. I think it's
supposed not to happen, since calling ereport() again opens a new
recursion level, but then maybe errcontext doesn't depend on the
recursion level ... I haven't checked. This is why the TAP test would
be handy :-)

> Agreed. Will add a TAP test.

Great. This patch waits on that, then.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Sergei Kornilov 2018-03-06 18:32:08 Re: using index or check in ALTER TABLE SET NOT NULL
Previous Message Tom Lane 2018-03-06 17:36:43 Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.