Bruce Momjian wrote:
>
> This has been saved for the 8.4 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
Huh, no, this is a bug and should be fixed right away.
> ---
>
> Tom Lane wrote:
> > "Kurt Ha
On Tue, 15 May 2007, Jim C. Nasby wrote:
Speaking of reviewers... should we put some thought into how we can
increase the number of people who can review code? It seems that's one
of our biggest bottlenecks...
Having recently dragged myself from never seeing the code before to being
able to p
On 5/16/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Yep, that is part of our problem, but even items people have already
said they _can_ review have shown little progress.
For complex patches, it might help to identify and associate a core/senior
community member in the early stages of de
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
>> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>>> On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:
I seem to recall there was a way to construct scenarios that returned
multiple
result set
Marc G. Fournier wrote:
I disagree with that approach. Larger more complex patches required
much more work and effort than small, simple ones. Not only do I
think it's unfair to the authors who spent considerably more time on
their work, but I think it also sets a bad precedent for future work;
Marc G. Fournier wrote:
> > Jonah H. Harris wrote:
> >> On 5/16/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
> >> > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4
> >> > ... if that means those 'large patches' don't get applied, so be it ...
> >>
> >> I disagree with tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, May 16, 2007 21:04:27 -0400 Bruce Momjian <[EMAIL PROTECTED]>
wrote:
> Jonah H. Harris wrote:
>> On 5/16/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
>> > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
> "Kurt Harriman" <[EMAIL PROTECTED]> writes:
> > Just noticed buffile.c:292 doesn't look quite right
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Jim Nasby wrote:
> On May 6, 2007, at 8:07 PM, Tom Lane wrote:
> > Jim Nasby <[EMAIL PROTECTED]> writes:
> >> Also, w
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Dawid Kuroczko wrote:
> Hello, I have a system where there are mostly COPYs,
> which insert data into a table. Ocasi
On Wed, May 16, 2007 at 09:32:44PM +0100, Richard Huxton wrote:
> Dave Page wrote:
> >Richard Huxton wrote:
> >>Magnus Hagander wrote:
> >>It's been on my list to rewrite the whole archive system for a while
> >>for various reasons. There is quite a bit of crossover with the patch
> >>t
Jonah H. Harris wrote:
> On 5/16/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
> > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ...
> > if
> > that means those 'large patches' don't get applied, so be it ...
>
> I disagree with that approach. Larger more complex patc
On Wed, May 16, 2007 at 07:48:10PM +0200, Magnus Hagander wrote:
> Dave Page wrote:
> >>> I the current URLs represent the month, and the ID of the message as
> >>> it comes out of the mbox I believe. We could probably write a script
> >>> to dump a list of message IDs, directories and mbox positio
On 5/16/07, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if
that means those 'large patches' don't get applied, so be it ...
I disagree with that approach. Larger more complex patches required
much more work and effort
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, May 16, 2007 20:09:44 -0400 Bruce Momjian <[EMAIL PROTECTED]>
wrote:
>
> I think one of the things that is preventing urgency is that everyone
> knows we have large patches unapplied, so they know that their lack of
> activity is
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Ko
Greg Stark <[EMAIL PROTECTED]> writes:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:
>>> I seem to recall there was a way to construct scenarios that returned
>>> multiple
>>> result sets via rules but I don't know how to arrange tha
I think one of the things that is preventing urgency is that everyone
knows we have large patches unapplied, so they know that their lack of
activity is not holding up the release. Any way around that?
---
bruce wrote:
> In
On Wed, 2007-05-16 at 10:31 -0700, Luke Lonergan wrote:
> I think the analysis on syncscan needs to take the external I/O cache into
> account. I believe it is not necessary or desirable to keep the scans in
> lock step within the PG bufcache.
I partially agree. I don't think we need any huge amo
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:
> >
> > I seem to recall there was a way to construct scenarios that returned
> > multiple
> > result sets via rules but I don't know how to arrange that. Anyone remember?
>
> An ALSO SE
Dave Page wrote:
Richard Huxton wrote:
Magnus Hagander wrote:
It's been on my list to rewrite the whole archive system for a while
for various reasons. There is quite a bit of crossover with the patch
tracker I proposed so I was hoping to look at both together.
Let me know when you start on th
Richard Huxton wrote:
> Magnus Hagander wrote:
> It's been on my list to rewrite the whole archive system for a while
> for various reasons. There is quite a bit of crossover with the patch
> tracker I proposed so I was hoping to look at both together.
Let me know when you start on
Magnus Hagander wrote:
It's been on my list to rewrite the whole archive system for a while
for various reasons. There is quite a bit of crossover with the patch
tracker I proposed so I was hoping to look at both together.
Let me know when you start on that...
Roger.
Same here - I've done som
On 5/16/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
I care. I want a professional easy to understand and easy to maintain
that doesn't cause potential conflict with future and past development
syntax.
You've just tempted me to create embedded SQL in assembly :)
--
Jonah H. Harris, Software
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Alvaro Herrera wrote:
>>> This is even better than our archives due to the problem that the
>>> archives don't have links to messages crossing month boundaries. Have
>>> you noticed that if you go to the archives, some discussions appe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> This is even better than our archives due to the problem that the
>> archives don't have links to messages crossing month boundaries. Have
>> you noticed that if you go to the archives, some discussions appear
>> truncated at a p
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> This is even better than our archives due to the problem that the
>> archives don't have links to messages crossing month boundaries. Have
>> you noticed that if you go to the archives, some discussions appear
>> truncated at a p
Ron Mayer wrote:
Andrew Dunstan wrote:
Josh Berkus wrote:
I think that may be where we're heading. In that case, we may need to
talk about branching earlier so that developers can work on the new
version who are frozen out of the in-process one.
I've argued this in the past. But be aware that
Andrew Dunstan wrote:
> Josh Berkus wrote:
>> I think that may be where we're heading. In that case, we may need to
>> talk about branching earlier so that developers can work on the new
>> version who are frozen out of the in-process one.
>
> I've argued this in the past. But be aware that it wi
What about a mentoring schema in order to push up the gap that
represents catching up with cases like the one Andrew posted?
By the way, being a patch reviewer doesn't represents also to be able
to find out potential problems in the code, which may have nothing to
do with the patch functionality?
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>> In talking to people who are assigned to review patches or could review
>> patches, I often get the reply, "Oh, yea, I need to do that".
>>
>> Folks, we are six weeks into feature freeze and have made slim progress
>> on getting patches reviewed
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > In talking to people who are assigned to review patches or could review
> > patches, I often get the reply, "Oh, yea, I need to do that".
> >
> > Folks, we are six weeks into feature freeze and have made slim progress
> > on getting patches rev
Joshua D. Drake wrote:
> Bruce Momjian wrote:
>> It is all on the developer roadmap page:
>>
>> http://momjian.us/cgi-bin/pgpatches
>>
>
> There is also a slightly more readable one here:
>
> http://developer.postgresql.org/index.php/Todo:PatchStatus
note that http://momjian.us/cgi-bin/pgpat
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe the thing to do here is to disallow running a postmaster when the
> data dir is using a different WAL magic (forcing you to pg_resetxlog or
> initdb).
Which, curiously enough, is exactly what it does ...
I'm not particularly concerned with the us
Dave Page wrote:
>>> I the current URLs represent the month, and the ID of the message as
>>> it comes out of the mbox I believe. We could probably write a script
>>> to dump a list of message IDs, directories and mbox positions I
>>> imagine, and then import that into a new database.
>>
>> Yeah,
Bruce Momjian wrote:
In talking to people who are assigned to review patches or could review
patches, I often get the reply, "Oh, yea, I need to do that".
Folks, we are six weeks into feature freeze and have made slim progress
on getting patches reviewed and applied. As I stated earlier, we a
Jim C. Nasby wrote:
On Wed, May 16, 2007 at 04:34:56PM +0100, Dave Page wrote:
How much visibility do we have into the mhonarc database? We should be
able to come up with a simple redirector that would point the old
mhonarc URLs to URLs for the new system...
database?
And here I thought the r
Bruce Momjian wrote:
It is all on the developer roadmap page:
http://momjian.us/cgi-bin/pgpatches
There is also a slightly more readable one here:
http://developer.postgresql.org/index.php/Todo:PatchStatus
Joshua D. Drake
--
I think the analysis on syncscan needs to take the external I/O cache into
account. I believe it is not necessary or desirable to keep the scans in
lock step within the PG bufcache.
The main benefit of a sync scan will be the ability to start the scan where
other scans have already filled the I/O
It is all on the developer roadmap page:
http://momjian.us/cgi-bin/pgpatches
---
Guido Barosio wrote:
> Bruce, where can I take a look at the patch list in order to find out
> if I can be of some help?
>
> Regards,
Bruce, where can I take a look at the patch list in order to find out
if I can be of some help?
Regards,
g.-
On 5/16/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
In talking to people who are assigned to review patches or could review
patches, I often get the reply, "Oh, yea, I need to do that".
Bruce Momjian wrote:
In talking to people who are assigned to review patches or could review
patches, I often get the reply, "Oh, yea, I need to do that".
It seems there is a lot of reliance on Tom to get the patches applied,
but I don't think that is fair or reasonable. I think we need more
ur
In talking to people who are assigned to review patches or could review
patches, I often get the reply, "Oh, yea, I need to do that".
Folks, we are six weeks into feature freeze and have made slim progress
on getting patches reviewed and applied. As I stated earlier, we are
now looking at August/
> I care. I want a professional easy to understand and easy to maintain
> that doesn't cause potential conflict with future and past development
> syntax.
I agree with this. The point of my comment was that ISTM that an
arbitrary amount of time can be consumed determining the optimal syntax,
du
Robert Haas wrote:
hate the fact that FTS is a separate module.
Here here.
And with respect to the debate about syntax, who cares? I think I
prefer introducing real SQL-ish syntax over a bunch of pg_* functions,
but doing it either way is IMHO better than doing nothing.
I care. I want a
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Tuesday, May 15, 2007 16:33:32 -0700 "Joshua D. Drake"
<[EMAIL PROTECTED]> wrote:
If the developers were to actually take a step back and say, "Hey... instead
of working on these dozen different features, I shoul
[EMAIL PROTECTED] (Aidan Van Dyk) writes:
> * Tatsuo Ishii <[EMAIL PROTECTED]> [070516 07:23]:
>
>> Maybe. However I think "subject-sequence" has some advantages over
>> Message-Id:
>>
>> - Easy to identify. Message-Id may not appear on some MUA with default
>> setting
>>
>> - More handy than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Wednesday, May 16, 2007 10:36:42 -0500 "Jim C. Nasby"
<[EMAIL PROTECTED]> wrote:
> On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote:
>> Someone (you, I think) advocated a '3 weeks and then dump the rest of the
>> patches' (no
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Neil Conway wrote:
> What is the reasoning behind having two different implementations of the
> datetime types, with
Aidan Van Dyk wrote:
> * Tatsuo Ishii <[EMAIL PROTECTED]> [070516 07:23]:
>
> > Maybe. However I think "subject-sequence" has some advantages over
> > Message-Id:
> >
> > - Easy to identify. Message-Id may not appear on some MUA with default
> > setting
> >
> > - More handy than lengthy messa
On Wed, May 16, 2007 at 04:34:56PM +0100, Dave Page wrote:
> >How much visibility do we have into the mhonarc database? We should be
> >able to come up with a simple redirector that would point the old
> >mhonarc URLs to URLs for the new system...
>
> database?
And here I thought the reason we u
On Wed, 2007-16-05 at 11:25 -0400, Bruce Momjian wrote:
> Are we agreed to wait for 8.4 for this?
Yes.
-Neil
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/abo
On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:
>
> I'm looking for corner cases where the concurrent psql patch doesn't handle
> things properly. I'm wondering about multiple result sets but I can't think of
> any cases where I can test them.
>
> If you submit multiple commands at
On Wed, May 16, 2007 at 12:33:38AM -0300, Marc G. Fournier wrote:
> Someone (you, I think) advocated a '3 weeks and then dump the rest of the
> patches' (not quote as strong of wording, but similar) ... why not split the
> patches list up:
>
> submitted patches, not reviewed
> reviewed patches,
Jim C. Nasby wrote:
How much visibility do we have into the mhonarc database? We should be
able to come up with a simple redirector that would point the old
mhonarc URLs to URLs for the new system...
database?
It's a file system. It simply generates HTML (or in our case) PHP files
from each
On Wed, May 16, 2007 at 08:58:44AM +0100, Dave Page wrote:
> Jim C. Nasby wrote:
> > On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
> >> Stefan Kaltenbrunner wrote:
> They are not stable. The items should point to the archives, which are
> supposedly more stable. (I ha
Are we agreed to wait for 8.4 for this?
---
Neil Conway wrote:
> What is the reasoning behind having two different implementations of the
> datetime types, with slightly different behavior? Do we intend to keep
> supporting
On Wed, May 16, 2007 at 10:46:50AM -0400, Alvaro Herrera wrote:
> > > I am not sure. We will have to investigate more the capabilities of the
> > > bug tracking system we intend to use. In the worst case one could add
> > > the URL for the archived message copy; second worst would be bouncing
> >
On Wed, May 16, 2007 at 09:43:36AM -0400, Gregory Stark wrote:
>
> I'm looking for corner cases where the concurrent psql patch doesn't
> handle things properly. I'm wondering about multiple result sets but
> I can't think of any cases where I can test them.
>
> If you submit multiple commands at
Has this been done yet? I don't think so.
---
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote:
> >> (1) I believe the reasoning for Tom's earlier change was
> > Here here.
> >
> Where? Where? Oh, you mean "Hear Hear." (sorry - one of my pet peeves)
Oops. Of course since it's in written form perhaps I should be writing
"Read! Read!" instead.
> We do have a responsibility, I think, to keep the grammar fairly
clean,
> so the answer to your question
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Dany DeBontridder wrote:
> I often need in command line to get the code of function, so I make a patch
> for pg_dump
Alvaro Herrera wrote:
> > > I am not sure. We will have to investigate more the capabilities of the
> > > bug tracking system we intend to use. In the worst case one could add
> > > the URL for the archived message copy; second worst would be bouncing
> > > (hopefully not forward) the interesting
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> > > > Bruce Momjian wrote:
> > > > > Alvaro Herrera wrote:
> > > >
> > > > > > In Debian's bug tracking system, when the bug is created (which is
> > > > > > done
> > > > > > by sending an email to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 10:03:47AM -0400, Alvaro Herrera wrote:
> [EMAIL PROTECTED] wrote:
[...]
> There is just one remaining problem: Outlook and derivatives don't set
> the In-Reply-To: nor References: headers. This breaks the threads (the
> best
* Tatsuo Ishii <[EMAIL PROTECTED]> [070516 07:23]:
> Maybe. However I think "subject-sequence" has some advantages over
> Message-Id:
>
> - Easy to identify. Message-Id may not appear on some MUA with default
> setting
>
> - More handy than lengthy message Id
>
> - Easy to detect messages no
Tatsuo Ishii wrote:
> > * Tatsuo Ishii <[EMAIL PROTECTED]> [070515 21:19]:
> >
> > > As I proposed for many times, why don't we add message number to each
> > > subject line in mail? For example like this:
> > >
> > > [HACKERS: 12345] Re: Not ready for 8.3
> > >
> > > This way, we could always
[EMAIL PROTECTED] wrote:
> On Wed, May 16, 2007 at 10:16:43AM +0900, Tatsuo Ishii wrote:
> > > Stefan Kaltenbrunner wrote:
> > > >> They are not stable. [...]
>
> > As I proposed for many times, why don't we add message number to each
> > subject line in mail? For example like this:
> >
> > [HACK
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Alvaro Herrera wrote:
> > >
> > > > > In Debian's bug tracking system, when the bug is created (which is
> > > > > done
> > > > > by sending an email to a certain address) it gets a number, a
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Alvaro Herrera wrote:
> >
> > > > In Debian's bug tracking system, when the bug is created (which is done
> > > > by sending an email to a certain address) it gets a number, and the
> > > > email is distributed to certain
I'm looking for corner cases where the concurrent psql patch doesn't handle
things properly. I'm wondering about multiple result sets but I can't think of
any cases where I can test them.
If you submit multiple commands at the psql prompt then psql seems to stop at
the first semicolon and send th
Robert Haas wrote:
Our users hate the fact that FTS is a separate module.
Here here.
Where? Where? Oh, you mean "Hear Hear." (sorry - one of my pet peeves)
And with respect to the debate about syntax, who cares? I think I
prefer introducing real SQL-ish syntax over a bunch of pg_
Am Mittwoch, 16. Mai 2007 05:37 schrieb Josh Berkus:
> I'm going to echo Bruce on this; I've mentioned that TSearch was going into
> Core at conferences and the reaction from existing users has been very
> enthusiastic, ranging from "yippee!" to "about time!". Our users hate the
> fact that FTS is
Am Mittwoch, 16. Mai 2007 05:37 schrieb Josh Berkus:
> In that case, we may need to talk
> about branching earlier so that developers can work on the new version who
> are frozen out of the in-process one.
Well, we could branch right now, but who is going to commit anything into that
new head bra
> I'm going to echo Bruce on this; I've mentioned that TSearch was going
> into Core at conferences and the reaction from existing users has been
> very enthusiastic, ranging from "yippee!" to "about time!". Our users
> hate the fact that FTS is a separate module.
Here here.
And with respect
> * Tatsuo Ishii <[EMAIL PROTECTED]> [070515 21:19]:
>
> > As I proposed for many times, why don't we add message number to each
> > subject line in mail? For example like this:
> >
> > [HACKERS: 12345] Re: Not ready for 8.3
> >
> > This way, we could always obtain stable (logical) pointer, wit
* Tatsuo Ishii <[EMAIL PROTECTED]> [070515 21:19]:
> As I proposed for many times, why don't we add message number to each
> subject line in mail? For example like this:
>
> [HACKERS: 12345] Re: Not ready for 8.3
>
> This way, we could always obtain stable (logical) pointer, without
> reling on
Ühel kenal päeval, E, 2007-05-07 kell 13:57, kirjutas Andrew Dunstan:
>
> Tom Lane wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >> Tino Wildenhain wrote:
> >>
> >>> Andrew Dunstan schrieb:
> >>>
> This does not need to be over-engineered, IMNSHO.
>
> > > > 32 buffers = 1MB with 32KB blocksize, which spoils the CPU L2
> > > > cache effect.
I'd say in a scenario where 32k pages are indicated you will also want
larger than average L2 caches.
> > > >
> > > > How about using 256/blocksize?
The reading ahead uses 1/4 ring size. To the best of
Michael Meskes wrote:
> On Wed, May 09, 2007 at 12:46:52PM +0100, Dave Page wrote:
>>> Unfortunately I do not have access to a Vista system I could use to test
>>> and track this one down.
>> I'm happy to run any tests you like.
>
> Dave, could you please apply this small patch to pgtypeslib/datet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 16, 2007 at 10:16:43AM +0900, Tatsuo Ishii wrote:
> > Stefan Kaltenbrunner wrote:
> > >> They are not stable. [...]
> As I proposed for many times, why don't we add message number to each
> subject line in mail? For example like this:
>
>
Jim C. Nasby wrote:
> On Tue, May 15, 2007 at 10:32:14PM +0200, Magnus Hagander wrote:
>> Stefan Kaltenbrunner wrote:
They are not stable. The items should point to the archives, which are
supposedly more stable. (I had already fixed one item in PatchStatus
this morning). Really i
Erik Aronesty wrote:
>
> Is pg_comparator the only project out there that does what it does?
>
http://www.sqlmanager.net/en/products/postgresql/dbcomparer
http://www.sqlmanager.net/en/products/postgresql/dbcomparer
http://pgdiff.sourceforge.net/ http://pgdiff.sourceforge.net/
http://apgdiff.s
83 matches
Mail list logo
