Re: [PATCHES] WIP 2 interpreters for plperl
От | Andrew Dunstan |
---|---|
Тема | Re: [PATCHES] WIP 2 interpreters for plperl |
Дата | |
Msg-id | 4558A860.5090006@dunslane.net обсуждение исходный текст |
Ответ на | Re: [PATCHES] WIP 2 interpreters for plperl (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: [PATCHES] WIP 2 interpreters for plperl
|
Список | pgsql-hackers |
I wrote: > > [moving to -hackers] > > I wrote: >> >>> >>> I have made some progress with what I think is needed to have two >>> interpreters for plperl. This is a lot harder than the pltcl case >>> for two reasons: 1. there are no restrictions on having 2 tcl >>> interpreters, and 2. tcl does not need to save and restore context >>> as we have to do with perl. I think I have a conceptual siolution to >>> these two problems, but what I have is currently segfaulting >>> somewhat myteriously. Tracing a dynamically loaded library in a >>> postgres backend with a debugger is less than fun, too. I am >>> attaching what I currently have, liberally sprinkled with >>> elog(NOTICE) calls as trace writes. >>> >>> >> >> With a little more perseverance I found the problem. The attached >> patch passes regression. But it now needs plenty of eyeballs and >> testing. >> >> > > Well, if anyone cast eyeballs over it they kept it secret from me :-( > > > However, I have now tested the patch with the little script shown > below and it seems to do the Right Thing (tm) in switching context and > restoring it. So I think it can be applied to HEAD, along with an > addition to the docs and a release note. > > Since this is a behaviour modification, do we want to apply it to the > back branches? Doing so would certainly be possible, although it would > be non-trivial. > I have committed this to HEAD at any rate, so that we can get some buildfarm testing going. cheers andrew
В списке pgsql-hackers по дате отправления: