On Thu, Jun 4, 2009 at 5:23 PM, Andrew Dunstan and...@dunslane.net 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
Dave Page wrote:
On Thu, Jun 4, 2009 at 5:23 PM, Andrew Dunstan and...@dunslane.net 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
On Fri, Jun 5, 2009 at 1:19 PM, Andrew Dunstan and...@dunslane.net 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:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan and...@dunslane.net 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
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan and...@dunslane.net 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
Magnus Hagander wrote:
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan wrote:
Magnus Hagander wrote:
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan and...@dunslane.net
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
Andrew Dunstan and...@dunslane.net 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.
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Magnus Hagander wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan and...@dunslane.net
wrote:
Of course, that leaves the issue of the library name to be fixed, but
sufficient unto the day ...
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 is
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
David E. Wheeler da...@kineticode.com 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.
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.net/
Josh Berkus j...@agliodbs.com 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
Magnus Hagander mag...@hagander.net 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,
Tom Lane wrote:
Magnus Hagander mag...@hagander.net 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
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
On Wed, Jun 3, 2009 at 11:54 PM, Andrew Dunstan and...@dunslane.net 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:
Dave Page wrote:
On Wed, Jun 3, 2009 at 11:54 PM, Andrew Dunstan and...@dunslane.net 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
Kris Jurka bo...@ejurka.com 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
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
On Tue, Jun 2, 2009 at 8:26 PM, Josh Berkus j...@agliodbs.com 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
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
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
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 not
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
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'
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
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
--
Josh Berkus j...@agliodbs.com 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
Josh Berkus j...@agliodbs.com 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
On Mon, Jun 1, 2009 at 2:09 PM, Josh Berkus j...@agliodbs.com 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
Robert Haas robertmh...@gmail.com 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
On Mon, Jun 1, 2009 at 3:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
Magnus Hagander mag...@hagander.net 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
Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com 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,
Joshua D. Drake j...@commandprompt.com 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
On Mon, Jun 1, 2009 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us 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
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
42 matches
Mail list logo
