Re: BUG #18070: Assertion failed when processing error from plpy's iterator

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #18070: Assertion failed when processing error from plpy's iterator
Дата
Msg-id ZQY/Nfv20tt4PBzA@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #18070: Assertion failed when processing error from plpy's iterator  (Alexander Lakhin <exclusion@gmail.com>)
Ответы Re: BUG #18070: Assertion failed when processing error from plpy's iterator  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On Sat, Sep 16, 2023 at 08:00:00PM +0300, Alexander Lakhin wrote:
> This lengthy output is similar to what we get with a recursion in plperl,
> so I don't consider this as an issue, but may be we could just check
> the length of an error message before concatenation...
>
> Please look at the v2 patch, which contains an addition to regression tests for the master.
> If you agree with this approach, I'll make patches for back branches as well...

+DETAIL:  spiexceptions.InvalidDatetimeFormat: invalid value "DD" for "DD"
+Value must be an integer.

That's the kind of things we've been doing for years in libpq.  So
even if there are no proper sentence terminations, that may be enough
for the user.

+        if (detail == NULL)
             detail = xmsg;
+        else if (xmsg != NULL) {
+            initStringInfo(&detailstr);
+            appendStringInfoString(&detailstr, xmsg);
+            appendStringInfoChar(&detailstr, '\n');
+            appendStringInfoString(&detailstr, detail);
+            detail = detailstr.data;
+        }

Perhaps it would be slightly cleaner to use a StringInfoData all the
time and rely on the presence of fmt to free the detail string?

Btw, backpatching a change in the error infrastructure does not seem a
good idea to me, as there could be applications that depend on the
existing behaviors?  It looks like we'd better just remove the
assertion in back-branches.
--
Michael

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Ilya Anfimov
Дата:
Сообщение: Re: BUG #18114: FULL JOIN is replaced by LEFT JOIN in plan
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #18070: Assertion failed when processing error from plpy's iterator