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-05 23:35:22
Message-ID: 20180305233522.gsmwzrryelpivqul@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I noticed that logicalrep_typmap_gettypname's only caller is
slot_store_error_callback, which is an error callback. So by raising an
error from the former, we would effectively just hide the actual reason
for the error behind the error that the cache entry cannot be found.

Therefore, I'm inclined to make this function raise a warning, then
return a substitute value (something like "unrecognized type XYZ"). Do
the same for the case with the mismatched major versions. Lastly, if
LogicalRepTypMap is not defined, also throw a warning and return a
substitute value rather than try to initialize the hash table:
initializing the table is not going to make the entry show up in it,
anyway, so it's pretty pointless; and there's plenty chance for things
to go wrong, which is not a good idea in an error callback.

Do we need a new TAP test for this? Judging by
showing all zeroes for the last function, we do. Same with
slot_store_error_callback in


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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-03-05 23:43:15 Re: 2018-03 Commitfest Summary (Andres #1)
Previous Message Michael Paquier 2018-03-05 23:32:31 Re: [HACKERS] Creating backup history files for backups taken from standbys