Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Tom Lane
Jim Nasby writes: > On 1/9/17 5:38 PM, Tom Lane wrote: >> 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. > Though, since a memory error could just as likely

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Jim Nasby
On 1/9/17 5:38 PM, Tom Lane wrote: Jim Nasby 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

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Tom Lane
Jim Nasby 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

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Jim Nasby
On 1/9/17 4:23 PM, Tom Lane wrote: Jim Nasby 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,

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Tom Lane
Jim Nasby 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

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Jim Nasby
On 1/9/17 3:12 PM, Jim Nasby wrote: I'm compiling 8.4 now, will see if I can duplicate. Got a stack trace. The abort happens in TclObjLookupVar: if (nsPtr->varResProc != NULL || iPtr->resolverPtr != NULL) { nsPtr itself is NULL. * thread #1: tid = 0x, 0x00010949bca8

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Jim Nasby
On 1/9/17 1:22 PM, Tom Lane wrote: I wrote: Pushed with that and some other, mostly-cosmetic changes. Hmm, looks like the new test cases have turned up a pre-existing bug. Some of the buildfarm is showing crashes :-(. It looks like all the unhappy critters are running Tcl 8.4.something,

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Tom Lane
I wrote: > Pushed with that and some other, mostly-cosmetic changes. Hmm, looks like the new test cases have turned up a pre-existing bug. Some of the buildfarm is showing crashes :-(. It looks like all the unhappy critters are running Tcl 8.4.something, which might be a coincidence but I bet

Re: [HACKERS] Increase pltcl test coverage

2017-01-09 Thread Tom Lane
Jim Nasby writes: > On 1/8/17 11:25 AM, Tom Lane wrote: >> But I don't understand >> how you got the sample output shown in the patch. Is this based >> on some unsubmitted changes in pltcl's error handling? > Maybe it's a version difference? > echo 'puts [info

Re: [HACKERS] Increase pltcl test coverage

2017-01-08 Thread Jim Nasby
On 1/8/17 11:25 AM, Tom Lane wrote: But I don't understand how you got the sample output shown in the patch. Is this based on some unsubmitted changes in pltcl's error handling? AFAICT you've got everything. What I had on my end is: create function public.tcl_error_handling_test(text)

Re: [HACKERS] Increase pltcl test coverage

2017-01-08 Thread Tom Lane
Jim Nasby writes: > On 1/6/17 2:17 PM, Tom Lane wrote: >> This is in a format that neither patch(1) nor "git apply" recognize. >> Please resubmit in a more usual format, diff -c or diff -u perhaps. > Odd, dunno what happened there. New patch attached. This applies, but

Re: [HACKERS] Increase pltcl test coverage

2017-01-07 Thread Jim Nasby
On 1/6/17 2:17 PM, Tom Lane wrote: Jim Nasby writes: On 10/31/16 3:24 PM, Jim Nasby wrote: This patch increases test coverage for pltcl, from 70% to 83%. Aside from that, the work on this uncovered 2 new bugs (the trigger return one I just submitted, as well as a bug

Re: [HACKERS] Increase pltcl test coverage

2017-01-06 Thread Tom Lane
Jim Nasby writes: > On 10/31/16 3:24 PM, Jim Nasby wrote: >> This patch increases test coverage for pltcl, from 70% to 83%. Aside >> from that, the work on this uncovered 2 new bugs (the trigger return one >> I just submitted, as well as a bug in the SRF/composite

Re: [HACKERS] Increase pltcl test coverage

2016-12-29 Thread Jim Nasby
On 10/31/16 3:24 PM, Jim Nasby wrote: This patch increases test coverage for pltcl, from 70% to 83%. Aside from that, the work on this uncovered 2 new bugs (the trigger return one I just submitted, as well as a bug in the SRF/composite patch). Rebased patch attached. Test coverage is now at

[HACKERS] Increase pltcl test coverage

2016-10-31 Thread Jim Nasby
This patch increases test coverage for pltcl, from 70% to 83%. Aside from that, the work on this uncovered 2 new bugs (the trigger return one I just submitted, as well as a bug in the SRF/composite patch). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics,