Alex Hunsaker writes:
> 3) patch postgres to fix the recursive issue (What I'm leaning towards)
> [ fixes both issues ]
How exactly would you propose doing that?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your su
On Thu, Feb 25, 2010 at 04:06:51PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
> >> There seem to be no good answers here.
>
> > There is one fairly good answer:
>
> > Use a perl that's compiled to support multiplicity but not
On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>> That's two unacceptable alternatives, you need to find a third one.
>> I think most people will have no trouble settling on "do not update
>> to Safe 2.2x" if you don't offer a better solution than these.
>
> I believe the next version of Safe wil
On Feb 25, 2010, at 1:08 PM, Alex Hunsaker wrote:
>> That solves the problem with recursion or with $a and $b or both?
>
> Yes ATM because we only kick in the extra security if you are on
> threads... Its a bit of a kludge in Safe. I know Tim wants to rectify
> that...
By adding the extra secur
On Thu, Feb 25, 2010 at 14:06, David E. Wheeler
wrote:
> On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote:
>> There is one fairly good answer:
>>
>> Use a perl that's compiled to support multiplicity but not threads.
> That solves the problem with recursion or with $a and $b or both?
Yes ATM becaus
Tim Bunce writes:
> On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
>> There seem to be no good answers here.
> There is one fairly good answer:
> Use a perl that's compiled to support multiplicity but not threads.
> That avoids the sort bug and, as an extra bonus, gives plperl
On Feb 25, 2010, at 12:58 PM, Tim Bunce wrote:
>> Which means losing sort $a <=> $b again, alas. Such was always the
>> case in the past, so that might be an okay tradeoff to get recursive
>> calls working again, but I certainly hope that Safe can be updated in
>> the near future to give us both.
On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
> On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>
> >> That's two unacceptable alternatives, you need to find a third one.
> >> I think most people will have no trouble settling on "do not update
> >> to Safe 2.2x" if you don't off
On Thu, Feb 25, 2010 at 13:03, Alex Hunsaker wrote:
> On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
>> Just don't break anything in 9.0 that relies on plperl please. :) To that
>> end, let me know when HEAD has something somewhat stable, and I'll
>> run some tests against it (e.g. Buc
On Thu, Feb 25, 2010 at 12:59, Greg Sabino Mullane wrote:
> Just don't break anything in 9.0 that relies on plperl please. :) To that
> end, let me know when HEAD has something somewhat stable, and I'll
> run some tests against it (e.g. Bucardo, which uses lots of plperl)
Defiantly, the goal is t
On Thu, Feb 25, 2010 at 12:31, David E. Wheeler
wrote:
> I think Tom meant, what sorts of changes to PostgreSQL do you think might
> solve the problem?
Here is what Tim said:
>Doesn't seem too icky. Basically plperl would need to save the values of
>PL_defstash, PL_incgv and PL_op_mask when a pl
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Well that's the thing, probably by what I described below that. Namely
> get something working for 9.1 and after we know its good and solid see
> if we can back patch it.
Just don't break anything in 9.0 that relies on plperl please. :) To th
On Feb 25, 2010, at 11:29 AM, Alex Hunsaker wrote:
> Well that's the thing, probably by what I described below that. Namely
> get something working for 9.1 and after we know its good and solid see
> if we can back patch it. Unfeasible? If its really really simple and
> straight forward maybe we
On Thu, Feb 25, 2010 at 12:20, Tom Lane wrote:
> Alex Hunsaker writes:
>> 3) patch postgres to fix the recursive issue (What I'm leaning towards)
>> [ fixes both issues ]
>
> How exactly would you propose doing that?
Well that's the thing, probably by what I described below that. Namely
get some
On Thu, Feb 25, 2010 at 11:04, David E. Wheeler
wrote:
> There seem to be no good answers here.
Yeah, Here is the thing I don't think we can fix 'safe' or even patch
perl to get recursive calls to work. Maybe Tim sees a way? We can
work around it in 9.0 with plperl.on_init. But breaking the ba
On Feb 25, 2010, at 10:01 AM, Tim Bunce wrote:
>> That's two unacceptable alternatives, you need to find a third one.
>> I think most people will have no trouble settling on "do not update
>> to Safe 2.2x" if you don't offer a better solution than these.
>
> I believe the next version of Safe wil
On Wed, Feb 24, 2010 at 10:58:17PM -0500, Tom Lane wrote:
> Alex Hunsaker writes:
> > On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
> >> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
> >>> Seems entirely unacceptable.
>
> >> I think we will see if we can get this fixed on the Safe/perl s
On Wed, Feb 24, 2010 at 22:01, Alex Hunsaker wrote:
> Ok I can get behind this. I did some testing and we could probably
> even store less than than that if we could do the equivalent of:
> Safe->share('::mksafefunc');
> pl_perl_createsub()
> Safe->unshare('::mksafefunc');
On 2nd thought this ba
On Feb 24, 2010, at 7:19 PM, Tom Lane wrote:
>> ISTM the easiest and safest fix would be to not allow recursive plperl
>> creations. You could still call plperl functions within functions,
>> just not if they are not defined. This limitation really blows
>
> That's the understatement of the mon
On Tue, Feb 23, 2010 at 15:54, Tim Bunce wrote:
> Doesn't seem too icky. Basically plperl would need to save the values of
> PL_defstash, PL_incgv and PL_op_mask when a plperl interpreter is
> initialized. And then local()'ly restore them in the plperl entry points.
> Should only be a few lines o
Alex Hunsaker writes:
> On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
>> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>>> Seems entirely unacceptable.
>> I think we will see if we can get this fixed on the Safe/perl side then.
> BTW the trade off here is we revert back to sort { $a <=>
On Wed, Feb 24, 2010 at 20:37, Alex Hunsaker wrote:
> On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>> Seems entirely unacceptable.
> I think we will see if we can get this fixed on the Safe/perl side then.
BTW the trade off here is we revert back to sort { $a <=> $b } not
working. That is if
On Wed, Feb 24, 2010 at 20:19, Tom Lane wrote:
>What you're saying, IIUC, is
> that if function A calls function B via a SPI command, and B wasn't
> executed previously in the current session, it would fail? Seems
> entirely unacceptable.
Yep, thats right :(. Thanks, thats exactly the kind of f
Alex Hunsaker writes:
> ISTM the easiest and safest fix would be to not allow recursive plperl
> creations. You could still call plperl functions within functions,
> just not if they are not defined. This limitation really blows
That's the understatement of the month. What you're saying, IIUC,
On Wed, Feb 24, 2010 at 19:17, Alex Hunsaker wrote:
> On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
>
>> I believe (but haven't yet confirmed) that the problem here is recursion.
>> This affects all versions of PostgreSQL.
> Ill keep digging.
Ok I understand now, basically the problem is (as
On Tue, Feb 23, 2010 at 15:23, Tim Bunce wrote:
> I believe (but haven't yet confirmed) that the problem here is recursion.
> This affects all versions of PostgreSQL.
Hrm... This seems to work for me in HEAD. It certainly breaks in 8.3.
Am I missing something?
$ bin/psql postgres
psql (9
On Tue, Feb 23, 2010 at 02:59:05PM -0700, Alex Hunsaker wrote:
> On Tue, Feb 23, 2010 at 14:29, Tim Bunce wrote:
> > David Wheeler has discovered a new PL/Perl failure when using Safe 2.2x.
>
> *sigh*.
>
> Thanks for all the testing David! And of course many thanks to Tim
> for all the hours of
[Resend. I misspelled the mailing list address on the original.]
David Wheeler has discovered a new PL/Perl failure when using Safe 2.2x.
It's not good.
In this email I'll try to explain the cause and some possible solutions.
PL/Perl compiles plperl functions inside a 'Safe compartment' which
r
28 matches
Mail list logo
