Re: [HACKERS] Increase pltcl test coverage

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [HACKERS] Increase pltcl test coverage
Дата
Msg-id 8b774ba6-8690-e0ec-fa8b-12f3f6f6165d@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Increase pltcl test coverage  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Increase pltcl test coverage  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 1/9/17 4:23 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@bluetreble.com> writes:
>> Got a stack trace. The abort happens in TclObjLookupVar:
>
> Yeah, I found the problem: pltcl_returnnext calls pltcl_build_tuple_result
> which may throw elog(ERROR), leaving the Tcl interpreter's state all
> screwed up, so that later functions go south.  It seems quite accidental
> that this is only failing with 8.4.  We need pltcl_returnnext to use a
> subtransction, like the other pltcl statements that can call into generic
> PG code.  Working on a fix now.

Hmm... I suspect there's more places where this could be a problem. For 
example, pltcl_quote calls palloc, which could ereport as well.

Perhaps all of the internal commands should be wrapped in the 
pltcl_subtrans_begin() construct. The subtrans overhead would be 
unfortunate though. But AFAIK the only reason we need the subtrans is if 
we're underneath a TCL catch command, and there's probably a way to 
determine if that's the case.

BTW, now that I've seen this pattern in pltcl and plpythonu, I'm 
wondering if there might be some easier way to handle it through our 
error callbacks.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)



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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATEand DELETE
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: [HACKERS] merging some features from plpgsql2 project