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/
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 it would be
-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:
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/datetime.c.
I
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 our knowledge,
Ü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.
Well could you explain where
* 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
* 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
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 to the
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
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 a
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_*
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
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 lists. People can
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, and the
email is
[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:
[HACKERS: 12345] Re:
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 obtain stable (logical)
* 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 not delivered,
-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 the
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 a certain address) it gets a
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 messages
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,
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 who
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 not to
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 the
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
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 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 had already fixed
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...
coughdatabase?/cough
It's a file system. It simply generates HTML (or in our case) PHP files
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,
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 the
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
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...
coughdatabase?/cough
And here I thought the reason
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 message Id
- Easy
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
-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' (not quote
[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 lengthy message Id
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 should
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
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,
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
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
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.
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,
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
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
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...
coughdatabase?/cough
And here I
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
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, if the files
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
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/pgpatches
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 and
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 and applied.
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
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 will make
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 point, but
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 point, but
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 appear
truncated
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
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
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 that...
Roger.
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
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 SELECT rule?
It
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
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
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 that. Anyone
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.
---
-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 not
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
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 positions I
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 patches
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
tracker I proposed so I was
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.
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, what
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 where
-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
... if
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 that approach. Larger
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
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 sets via rules but I don't
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
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
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 Harriman
82 matches
Mail list logo
