Re: [HACKERS] Increase pltcl test coverage

On 1/9/17 5:38 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@bluetreble.com> writes:
>> Hmm... I suspect there's more places where this could be a problem. For
>> example, pltcl_quote calls palloc, which could ereport as well.
>
> Yeah.  I looked at that but couldn't get terribly excited about it,
> because AFAICS, Tcl in general is apt to fall over under sufficient
> memory pressure.  There are too many API functions with no failure
> return provision, even though they clearly must do memory allocation
> under the hood.  (The fact that they've even got ckalloc() tells you
> what their philosophy is here: they're content to PANIC on OOM.)

Uhm... wow. According to [1] that's going to result in TCL calling 
abort(). I'm guessing there's no reasonable way for us to recognize a 
TCL abort as something that we didn't need to panic on...

In any case, AFAICT there's still a bug here: if PG hits a memory error, 
we'll ERROR, which is going to leave the interpreter right back in a bad 
state for the rest of that session. That doesn't seem so good. It also 
means a pltcl proc wouldn't get the chance to trap the error.

Though, since a memory error could just as likely come out of tcl, which 
is going to panic us anyway, I guess it doesn't matter.

> I think pltcl should attempt to cover any error conditions that aren't
> purely out-of-memory ones, but in a quick scan I didn't see any other
> hazards.

Yeah, I think we're OK on that front.

I was hoping to establish a precedent for all the new TCL functions that 
pltcl provides so it would be extremely unlikely that the returnnext bug 
could be repeated. Putting them in a separate file with a nice comment 
block would be another alternative.
-- 
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)