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 sn
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 member
> -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 -
"Dave Page" 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 increase your free spac
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 res
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 Chaudhu
Many patch submitters discover that they fall foul of various "you
should have done"s 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 result
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 pl
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 d
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 eve
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
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 wo
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 a
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 set
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 remembe
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 revie
19 matches
Mail list logo
