From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Karl Lehenbauer <karl(at)flightaware(dot)com> |
Subject: | Re: Increase pltcl test coverage |
Date: | 2017-01-09 23:38:27 |
Message-ID: | 9849.1484005107@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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.)
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-01-09 23:39:04 | Re: Make pg_basebackup -x stream the default |
Previous Message | Andrew Dunstan | 2017-01-09 23:33:39 | Re: merging some features from plpgsql2 project |