On Wed, Mar 7, 2018 at 2:52 AM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Masahiko Sawada wrote:
>> On Tue, Mar 6, 2018 at 8:35 AM, Alvaro Herrera <alvherre@alvh.no-ip.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 :-)
The calling ereport opens a new recursion level. The calling ereport
with error doesn't return to caller but the calling with warning does.
So the recursively calling ereport(WARNING) ends up with exceeding the
errordata stack size. So it seems to me that we can set errcontext in
logicalrep_typmap_gettypname() instead of raising warning or error.
>
>> Agreed. Will add a TAP test.
>
> Great. This patch waits on that, then.
>
Okay. I think the most simple and convenient way to reproduce this
issue is to call an elog(LOG) in input function of a user-defined data
type. So I'm thinking to create the test in src/test/module directory.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center