From: | bricklen <bricklen(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: plperlu function caused a segmentation fault |
Date: | 2011-08-24 20:26:17 |
Message-ID: | CAGrpgQ8dkNu8O1E5DzAeJAE2vXH1bjvWSMHr5VQi4FRtXYqTqw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Aug 24, 2011 at 1:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I agree you probably don't want to poke at this in your production
> instance, but you could create a playpen instance (separate data
> directory, nondefault port number) using the same executables and
> then do your testing there. If you didn't want to get plperl going
> on that machine, why'd you try it in the first place?
Good idea about using a separate data dir etc, I'll try that out.
As far as not wanting plperl in the first place, I didn't mean to
imply that. I've used plperl(u) functions before (but not since 8.4),
so it was never an issue on this particular production machine before.
I've had no problems in the other dev and test databases where I've
found uses for plperl functions -- none are currently lower than 9.0.4
however.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2011-08-24 20:41:10 | Re: postgresql server crash on windows 7 when using plpython |
Previous Message | Tom Lane | 2011-08-24 20:16:58 | Re: plperlu function caused a segmentation fault |