And the fun continues :-)
-Original Message-
From: PG Build Farm
[mailto:[EMAIL PROTECTED]
Sent: 14 February 2006 02:16
To: [EMAIL PROTECTED]
Subject: PGBuildfarm member snake Branch HEAD Status changed
from Make failure to Contrib failure
The PGBuildfarm member snake had
Dave Page wrote:
And the fun continues :-)
-Original Message-
From: PG Build Farm
[mailto:[EMAIL PROTECTED]
Sent: 14 February 2006 02:16
To: [EMAIL PROTECTED]
Subject: PGBuildfarm member snake Branch HEAD Status changed
from Make failure to Contrib failure
The PGBuildfarm
-Original Message-
From: Mark Kirkwood [mailto:[EMAIL PROTECTED]
Sent: 14 February 2006 10:17
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] FW: PGBuildfarm member snake Branch
HEAD Status changed from Make failure to Contrib failure
Oh dear - looks
Dave Page dpage@vale-housing.co.uk writes:
And the fun continues :-)
Info: resolving _MaxFSMPages by linking to __imp__MaxFSMPages (auto-import)
Fixed.
regards, tom lane
---(end of broadcast)---
TIP 5: don't forget to
Mark Kirkwood [EMAIL PROTECTED] writes:
Oh dear - looks like my pg_freespacemap patch is getting its Windows
testing :-(
Dave - are you able to try out the attached patch?
Already committed an equivalent patch before seeing your message ...
regards, tom lane
Hello everyone,
I am working with the Postgres optimizer for the first time, so bear with me...
I want to extend the optimizer to deal with aggregate queries a bit
better. The idea is from an old paper by Chaudhuri and Shim in VLDB
94. The gist of it is that when computing aggregates over the
On Tue, Feb 14, 2006 at 10:35:12AM -0600, hector Corrada Bravo wrote:
Hello everyone,
I am working with the Postgres optimizer for the first time, so bear with
me...
I want to extend the optimizer to deal with aggregate queries a bit
better. The idea is from an old paper by Chaudhuri and
Many patch submitters discover that they fall foul of various you
should have dones at a late stage of the patch review process.
These include the usual:
- major feature change not discussed on -hackers or elsewhere first
- patch in wrong format
- performance patch, yet no performance test results
hector Corrada Bravo [EMAIL PROTECTED] writes:
1) Regardless of the optimization problem, is the executor able to
execute aggregate nodes within join trees (that is, not as the result
of subqueries)?
Sure.
3) For debugging purposes: Has anyone figured out a way to feed
hand-crafted plans to
On Mon, Feb 06, 2006 at 05:08:38PM -0500, Alon Goldshuv wrote:
The proposal is neat, however, I am not too
excited about handling errors in such high granularity, as far as the user
is concerned. I am more on the same line with Tom Lane's statement in
Simon's thread (Practical error logging
Note: People following this should probably read this post on -patches
in the archive:
http://archives.postgresql.org/pgsql-patches/2006-02/msg00207.php
On Tue, Feb 14, 2006 at 05:20:55PM +, Simon Riggs wrote:
Many patch submitters discover that they fall foul of various you
should have
Martijn van Oosterhout wrote:
Finally, several of the patches committed the last few days have been
fixing minor bugs or platform specific issues with various patches. One
thing that would be really nice is a real patch queue and have the
buildfarm machines occasionally apply one of the patches
On Tue, 2006-02-14 at 16:17 -0500, Andrew Dunstan wrote:
If I had enough time there are all sorts of things like this I'd love to
set up. A fetchable url that says try these experimental CVS branches
or something like that would be great.
How much time would you need? I think having every
On Tue, Feb 14, 2006 at 09:54:12PM +, Simon Riggs wrote:
On Tue, 2006-02-14 at 16:17 -0500, Andrew Dunstan wrote:
If I had enough time there are all sorts of things like this I'd love to
set up. A fetchable url that says try these experimental CVS branches
or something like that
Simon Riggs [EMAIL PROTECTED] writes:
How much time would you need? I think having every patch built before
anyone even looks at the code would sort out most of the issues I
mentioned.
If I ran a buildfarm machine, I'd turn it off immediately if anyone
proposed setting up a system that would
On Tue, 2006-02-14 at 17:28 -0500, Tom Lane wrote:
IMHO the thing we are really seriously short of is patch reviewers.
Neil and Bruce and I seem to be the only ones doing that much at all,
and the main burden is falling on Bruce. More eyeballs would help
much more than throwing machines at
Tom Lane said:
Simon Riggs [EMAIL PROTECTED] writes:
How much time would you need? I think having every patch built before
anyone even looks at the code would sort out most of the issues I
mentioned.
If I ran a buildfarm machine, I'd turn it off immediately if anyone
proposed setting up a
On Tuesday 14 February 2006 16:00, Martijn van Oosterhout wrote:
I would like to suggest that we increase substantially the FAQ entries
relating to patch submission. By we, I actually mean please could the
committers sit down and agree some clarified written guidelines?
As I remember,
On Tue, 2006-02-14 at 22:54 +, Simon Riggs wrote:
On Tue, 2006-02-14 at 17:28 -0500, Tom Lane wrote:
IMHO the thing we are really seriously short of is patch reviewers.
[...]
Well that was the basis of my original suggestion. Publish some
guidelines and everybody becomes a patch reviewer.
19 matches
Mail list logo
