On Fri, Jun 5, 2009 at 1:19 PM, Andrew Dunstan wrote:
>
>
> OK. try with this please:
>
> my @perl_libs = grep { /perl\d+.lib$/ }
> glob($solution->{options}->{perl} . '\lib\CORE\perl*.lib');
That looks good.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent
Dave Page wrote:
On Thu, Jun 4, 2009 at 5:23 PM, Andrew Dunstan wrote:
Yeah. The patch below should be far more future-proof (and past-proof, for
that matter).
Dave, any chance you can test it?
Doesn't work here, presumably because there is a PerlEz.lib in the
same directory as Pe
On Thu, Jun 4, 2009 at 5:23 PM, Andrew Dunstan wrote:
> Yeah. The patch below should be far more future-proof (and past-proof, for
> that matter).
>
> Dave, any chance you can test it?
Doesn't work here, presumably because there is a PerlEz.lib in the
same directory as Perl510.lib, causing the g
"David E. Wheeler" writes:
> On Jun 4, 2009, at 3:58 PM, Tom Lane wrote:
>> It seems we have two reasonable possibilities for 8.4: revert that
>> patch and keep contrib/intarray's behavior the same as it was, or leave the
>> patch in and document that there was a behavioral change.
> You can't
On Jun 4, 2009, at 3:58 PM, Tom Lane wrote:
It seems we have two reasonable possibilities for 8.4: revert that
patch
and keep contrib/intarray's behavior the same as it was, or leave the
patch in and document that there was a behavioral change.
You can't keep the patch and update intarray to
One of the other open items is:
>> contrib/intarray opclass definition needs updating
>> tgl says: done, but there's another problem; see also bug #4806
The state of play on this is:
* GIN cannot find items that generate no index entries, such as empty
arrays or empty text documents.
* This i
Magnus Hagander wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan
wrote:
Of course, that leaves the issue of the library name to be fixed, but
sufficient unto the day ...
Yea
Tom Lane wrote:
Andrew Dunstan writes:
I have cleaned up the patch from yesterday slightly, too. I'm wondering
how far back we should backpatch all this. This API was actually
documented in Perl (just) before 7.4 was released, so in theory the API
adjustment should go all the way back. H
Andrew Dunstan writes:
> I have cleaned up the patch from yesterday slightly, too. I'm wondering
> how far back we should backpatch all this. This API was actually
> documented in Perl (just) before 7.4 was released, so in theory the API
> adjustment should go all the way back. However, in prac
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> Dave Page wrote:
>>
>>> On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan
>>> wrote:
>>>
Of course, that leaves the issue of the library name to be fixed, but
sufficient unto the day ...
>>> Yeah - I chatted briefly
Magnus Hagander wrote:
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan wrote:
Of course, that leaves the issue of the library name to be fixed, but
sufficient unto the day ...
Yeah - I chatted briefly with Magnus about that a while back. I added
a quick hack
Dave Page wrote:
> On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan wrote:
>> Of course, that leaves the issue of the library name to be fixed, but
>> sufficient unto the day ...
>
> Yeah - I chatted briefly with Magnus about that a while back. I added
> a quick hack to Mkvcbuild.pm to allow it to
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan wrote:
>
> Well, that's not too easy to read, but anyway, I got to the bottom of it.
> Turns out there's a change in the Perl embedding API that nobody noticed.
> The attached patch worked for me on Windows. We'll need something like this
> on other
Dave Page wrote:
On Wed, Jun 3, 2009 at 11:54 PM, Andrew Dunstan wrote:
Update: the problem is apparently occurring during the call to perl_parse()
in plperl_init_interp().
Not sure if you saw the previous thread on this, but here's a
backtrace that gives some more detail:
http://a
On Wed, Jun 3, 2009 at 11:54 PM, Andrew Dunstan wrote:
>
>
> Update: the problem is apparently occurring during the call to perl_parse()
> in plperl_init_interp().
>
Not sure if you saw the previous thread on this, but here's a
backtrace that gives some more detail:
http://archives.postgresql.org
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Josh Berkus wrote:
* plperl fails with Perl 5.10 on Windows
o tgl says: no reports of this with pre-8.4 Postgres, but
I bet that's just because no one tried it
o dpage says: I'm rolling back the Windows installers to
Tom Lane wrote:
> Magnus Hagander writes:
>> Josh Berkus wrote:
>>> * Path separator consistency on Windows
>>>
>>> -- This discussion does not appear to have concluded. Magnus, Dave?
>
>> We've lived with this for a long time, it's nothing new. And it's not
>> critical. Bump to 8.5.
>
> This i
Magnus Hagander writes:
> Josh Berkus wrote:
>> * Path separator consistency on Windows
>>
>> -- This discussion does not appear to have concluded. Magnus, Dave?
> We've lived with this for a long time, it's nothing new. And it's not
> critical. Bump to 8.5.
This is partly my fault, since I ob
Josh Berkus writes:
> More suggested dispositions:
> * contrib/seg and contrib/cube GiST index support have performance issues
> -- If it's just a performance issue, I don't think this issue should
> block 8.4.0; it can be fixed in 8.4.1 if necessary, since we'll probably
> want to backpa
Josh Berkus wrote:
> Tom, all,
>
> * Path separator consistency on Windows
>
> -- This discussion does not appear to have concluded. Magnus, Dave?
We've lived with this for a long time, it's nothing new. And it's not
critical. Bump to 8.5.
--
Magnus Hagander
Self: http://www.hagander.n
Andrew Dunstan wrote:
Josh Berkus wrote:
* plperl fails with Perl 5.10 on Windows
o tgl says: no reports of this with pre-8.4 Postgres, but I
bet that's just because no one tried it
o dpage says: I'm rolling back the Windows installers to
use 5.8 for now. Would a
On Tue, 2009-06-02 at 17:26 -0700, Josh Berkus wrote:
>
> * possible bug in cover density ranking?
>
> -- From Teodor's response, this is maybe a doc patch and not a code
> patch. Teodor? Oleg?
I personally think that this is a bug, because we are assigning very
high rank when we are no
Josh Berkus wrote:
* plperl fails with Perl 5.10 on Windows
o tgl says: no reports of this with pre-8.4 Postgres, but I
bet that's just because no one tried it
o dpage says: I'm rolling back the Windows installers to use
5.8 for now. Would appreciate help from anyon
On Jun 2, 2009, at 5:26 PM, Josh Berkus wrote:
Tom, all,
More suggested dispositions:
* plperl fails with Perl 5.10 on Windows
o tgl says: no reports of this with pre-8.4 Postgres, but I
bet that's just because no one tried it
o dpage says: I'm rolling back the Windows
On Tue, Jun 2, 2009 at 8:26 PM, Josh Berkus wrote:
> * autovacuum can run rebuild_database_list unreasonably often
>
> -- A possible quick workaround would be to put a lower limit of naptime at
> 1s. This would save most people (those with 10 or less database) from
> triggering rebuild_databas
Tom, all,
More suggested dispositions:
* plperl fails with Perl 5.10 on Windows
o tgl says: no reports of this with pre-8.4 Postgres, but I
bet that's just because no one tried it
o dpage says: I'm rolling back the Windows installers to use
5.8 for now. Would appreciat
Kris Jurka writes:
> On Mon, 1 Jun 2009, Robert Haas wrote:
>> tgl says: whether or not we think PL/Java is bulletproof, there are
>> other problems, for instance this one
>> http://archives.postgresql.org/message-id/87zlnwnvjg@news-spur.riddles.org.uk
>>
>> That's a pretty overwhelming argum
On Mon, 1 Jun 2009, Robert Haas wrote:
Regarding this item:
* Consider reverting preventing regular users from base type creation
You raise this point:
tgl says: whether or not we think PL/Java is bulletproof, there are
other problems, for instance this one
http://archives.postgresql.org/me
On Mon, Jun 1, 2009 at 12:32 PM, Tom Lane wrote:
> As of today we are three months behind the original plan for 8.4.0 release.
> In a one-year release cycle that's already pretty bad slip; but there now
> seems no chance of a release happening in less than a month, and if we
> continue to let thin
"Joshua D. Drake" writes:
> On Mon, 2009-06-01 at 11:09 -0700, Josh Berkus wrote:
>> # adjust information_schema precision and scale fields?
>> -- save for 8.5
> I read this thread. It seems for the changes we can make we should just
> make them. The actual amount of change is actually very nomi
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Josh Berkus writes:
>>> cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
>> Actually I'm hoping that Kevin Grittner will have something to
>> report on that one soon
> So far, I haven't found any performance regressions in the
Tom Lane wrote:
> Josh Berkus writes:
>> cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
> Actually I'm hoping that Kevin Grittner will have something to
> report on that one soon
So far, I haven't found any performance regressions in the beta2
release compared to the sna
Magnus Hagander writes:
> Tom Lane wrote:
>>> # instrument the Windows shared memory reattachment problem?
>>
>> Yeah. That was put on the list a month ago, when there was still plenty
>> of time to do something about it; but since we missed getting it into
>> beta2 I think it will have to wait.
Tom Lane wrote:
> Josh Berkus writes:
>> # instrument the Windows shared memory reattachment problem?
>> -- as much as I'd like to do this, the solution could be as bad as the
>> problem; we'd need more testing time for new instrumentation. Will have
>> to deal with via testing patched versions
On Mon, Jun 1, 2009 at 3:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> I recommend we create
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items and start
>> bumping things that can't be completed for 8.4.
>
> Why not just the regular TODO list?
>
> Stuff that has plausible patches att
Robert Haas writes:
> I recommend we create
> http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items and start
> bumping things that can't be completed for 8.4.
Why not just the regular TODO list?
Stuff that has plausible patches attached can go directly to the
CommitFest_2009-First page, but
On Mon, Jun 1, 2009 at 2:09 PM, Josh Berkus wrote:
> Tom,
>
> Let me start this out by voting the things I think we can drop until 8.5:
>
> * gettext plurals patch needs some polishing
> -- revert patch, save for 8.5
>
> # adjust information_schema precision and scale fields?
> -- save for 8.5
>
Josh Berkus writes:
> Let me start this out by voting the things I think we can drop until 8.5:
> * gettext plurals patch needs some polishing
> -- revert patch, save for 8.5
Peter might think differently about that ;-). My problem with it is
that we don't seem to have a polished API for how co
Josh Berkus writes:
> # cost_nestloop and cost_hashjoin are broken for SEMI and ANTI joins
> * tgl says: I think this is mostly dealt with but it could use
> performance testing.
> Mark? Jignesh? Can you test this?
Actually I'm hoping that Kevin Grittner will have something to report
o
On Mon, 2009-06-01 at 11:09 -0700, Josh Berkus wrote:
> Tom,
> # adjust information_schema precision and scale fields?
> -- save for 8.5
I read this thread. It seems for the changes we can make we should just
make them. The actual amount of change is actually very nominal.
Joshua D. Drake
--
Tom,
Let me start this out by voting the things I think we can drop until 8.5:
* gettext plurals patch needs some polishing
-- revert patch, save for 8.5
# adjust information_schema precision and scale fields?
-- save for 8.5
# instrument the Windows shared memory reattachment problem?
-- as
As of today we are three months behind the original plan for 8.4.0 release.
In a one-year release cycle that's already pretty bad slip; but there now
seems no chance of a release happening in less than a month, and if we
continue to let things drift it could easily stretch to five or six
months' sl
42 matches
Mail list logo
