Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think what Tom is concerned about is that this hasn't been tested
enough with big datasets. Also there a little loss of index pages but
it's much less (orders of magnitude, I think) than what was before.
This is because the index
Bruce Momjian wrote:
The reason I'm waffling about whether the problem is completely fixed or
not is that the existing code will only remove-and-recycle completely
empty btree pages. As long as you have one key left on a page it will
stay there. So you could end up with ridiculously low
On Fri, Oct 03, 2003 at 09:17:16AM -0700, Joshua D. Drake wrote:
What if the feature does break compatibility with old features?
What if it is truly a new feature?
There is _no_ mechanism in the community right now for testing all
these new features in the so-called stable tree.
I have
Andrew Sullivan wrote:
On Fri, Oct 03, 2003 at 09:17:16AM -0700, Joshua D. Drake wrote:
What if the feature does break compatibility with old features?
What if it is truly a new feature?
There is _no_ mechanism in the community right now for testing all
these new features in the
Bruce Momjian wrote:
Andrew Sullivan wrote:
On Fri, Oct 03, 2003 at 09:17:16AM -0700, Joshua D. Drake wrote:
What if the feature does break compatibility with old features?
What if it is truly a new feature?
There is _no_ mechanism in the community right now for testing all
these
Andrew Dunstan wrote:
Agreed. Great Bridge was going to test our releases and only distribute
the good ones --- obviously they were thinking of Linux kernels and not
PostgreSQL. You almost need a commercial company to do testing with
Linux kernels. PostgreSQL doesn't require this, and I
Hello,
O.k. so everyone is basically in agreement of no new features to be
backported.
How do we implement a stable release maintainer for back releases? I assume
we set a scope of of what would go in security/bug fixes only?
Sincerely,
Joshua Drake
--
Command Prompt, Inc., home of Mammoth
Joshua D. Drake wrote:
But the kernel goes through this reliable/unreliable cycle --- they
would be better off just making the old kernel more and more reliable
and focusing on the new kernel for features.
The reliable/unreliable cycle will kill your user base.
The popularity of
But the kernel goes through this reliable/unreliable cycle --- they
would be better off just making the old kernel more and more reliable
and focusing on the new kernel for features.
The reliable/unreliable cycle will kill your user base.
The popularity of Linux would argue that statement a
Joshua D. Drake wrote:
eh.. i could see some things, like tsearch2 or pg_autovacuum, which
afaik are almost if not completely compatible with 7.3, which will not
get back ported. Also fixes in some of the extra tools like psql could
be very doable, I know I had a custom psql for 7.2 that back
I have lately been taking the position that Linux is only a
second-best choice for production use, precisely because of the
constant introduction of shiny new features in the supposed stable
branch.
That's what all us FreeBSD users learnt a long time ago :P
Chris
Bruce Momjian [EMAIL PROTECTED] writes:
By doing REINDEX always, we eliminate some folks are are happy
doing VACUUM FULL at night, because very few tuples are expired.
But if they have very few tuples expired, why do they need VACUUM FULL?
Seems to me that VACUUM FULL should be designed to
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
By doing REINDEX always, we eliminate some folks are are happy
doing VACUUM FULL at night, because very few tuples are expired.
But if they have very few tuples expired, why do they need VACUUM FULL?
Seems to me that VACUUM FULL
On Sat, Oct 04, 2003 at 11:53:49PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Imagine having to VACUUM FULL a huge
table. Not only it will take the lot required to do the VACUUM in the
heap itself, it will also have to rebuild all indexes from scratch.
A very large
Alvaro Herrera wrote:
Yeah, I think that's exactly the important point. These days there's
not a lot of reason to do VACUUM FULL unless you have a major amount of
restructuring to do. I would once have favored maintaining two code
paths with two strategies, but now I doubt it's worth the
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the indexes via REINDEX rather than
indexbulkdelete.
On Sat, Oct 04, 2003 at 11:41:17AM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the indexes via REINDEX rather than
On Sat, Oct 04, 2003 at 11:17:09PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we move empty index pages to the end before truncation during vacuum
full?
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated
Alvaro Herrera [EMAIL PROTECTED] writes:
On Sat, Oct 04, 2003 at 11:41:17AM -0400, Tom Lane wrote:
No. You'd be better off using REINDEX for that, I think. IIRC we have
speculated about making VAC FULL fix the indexes via REINDEX rather than
indexbulkdelete.
I can't agree with that idea.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No. You'd be better off using REINDEX for that, I think.
I guess my point is that if you forget to run regular vacuum for a
month, then realize the problem, you can just do a VACUUM FULL and the
heap is back to a perfect state as if
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No. You'd be better off using REINDEX for that, I think.
I guess my point is that if you forget to run regular vacuum for a
month, then realize the problem, you can just do a VACUUM FULL and the
heap is back to a
On Thu, Oct 02, 2003 at 02:15:33PM -0500, Bruno Wolff III wrote:
It might be better to split into two different trees. One just gets bug fixes,
the other gets bug fixes plus enhancements that won't require an initdb.
Yes, please. Please, please do not force all users to accept new
features in
Yes, please. Please, please do not force all users to accept new
features in stable trees.
What if the feature does break compatibility with old features?
What if it is truly a new feature?
One example would be that we are considering reworking
pg_dump/restore a bit to support batch uploads
Joshua D. Drake [EMAIL PROTECTED] writes:
Yes, please. Please, please do not force all users to accept new
features in stable trees.
What if the feature does break compatibility with old features?
What if it is truly a new feature?
One example would be that we are considering reworking
On Fri, 3 Oct 2003, Joshua D. Drake wrote:
Yes, please. Please, please do not force all users to accept new
features in stable trees.
What if the feature does break compatibility with old features?
What if it is truly a new feature?
One example would be that we are considering
Joshua, et. al.
Sorry for weighing in on this discussion so late; I've gotten behind on the
Hackers digests, since there are some 90 messages a day.
I don't see anything wrong with the idea of maintaining a 7.3 tree for bug
fixes and testing if /contrib modules can be backported. Heck, I'm
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think what Tom is concerned about is that this hasn't been tested
enough with big datasets. Also there a little loss of index pages but
it's much less (orders of magnitude, I think) than what was before.
This is because the index
Andrew Sullivan wrote:
On Thu, Oct 02, 2003 at 02:15:33PM -0500, Bruno Wolff III wrote:
It might be better to split into two different trees. One just gets bug fixes,
the other gets bug fixes plus enhancements that won't require an initdb.
Yes, please. Please, please do not force all
On Fri, 3 Oct 2003, Andrew Sullivan wrote:
On Thu, Oct 02, 2003 at 02:15:33PM -0500, Bruno Wolff III wrote:
It might be better to split into two different trees. One just gets bug fixes,
the other gets bug fixes plus enhancements that won't require an initdb.
Yes, please. Please, please
If we are going to back-patch more aggressively, we _have_ to be sure
that those back-patched releases have the same quality as all our other
releases.
I know that I am probably being semantic here but I in know way want to
be more aggressive with back patching. My
thoughts for 98% of things
Bruce Momjian [EMAIL PROTECTED] writes:
Though the new code will put empty index pages into the free-space map,
will it also shrink the index file to remove those pages?
If there are free pages at the end, yes --- but it won't move pages
around. This is about the same story as for plain VACUUM
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Though the new code will put empty index pages into the free-space map,
will it also shrink the index file to remove those pages?
If there are free pages at the end, yes --- but it won't move pages
around. This is about the same
Hello,
Possible scenario for maintaining 7.3:
Only one or two committers using a two stage cvs... one stage for
testing (not including sandbox), one stage for commit.
Scheduled releases based on non-critical fixes. Quarterly? Of course
critical fixes should be released as soon as
On Thu, Oct 02, 2003 at 10:47:06 -0700,
Joshua D. Drake [EMAIL PROTECTED] wrote:
Hello,
Possible scenario for maintaining 7.3:
Only one or two committers using a two stage cvs... one stage for
testing (not including sandbox), one stage for commit.
Scheduled releases based on
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what do people think about having a dedicated maintenance
team for 7.3? 7.3 is a pretty solid release and I think people will be
hard pressed to upgrade to
On Wed, 2003-10-01 at 08:36, Marc G. Fournier wrote:
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what do people think about having a dedicated maintenance
team for 7.3? 7.3 is a pretty solid
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what
do people think about having a dedicated maintenance team for 7.3? 7.3
is a pretty
solid release and I think people will be hard pressed to upgrade
On Wed, 1 Oct 2003, Robert Treat wrote:
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5 can stay focused on
that, but folks who can't upgrade to
Marc G. Fournier [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2003, Joshua D. Drake wrote:
Of course the theory being that we backport some features and fix
any bugs that we find?
Not saying that if someone submit'd patches to v7.3, they wouldn't get
applied ... only that, to date, the
On Wed, 2003-10-01 at 09:14, Robert Treat wrote:
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5 can stay focused on
that, but folks who can't
On Wed, 2003-10-01 at 10:49, Neil Conway wrote:
On Wed, 2003-10-01 at 09:14, Robert Treat wrote:
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5
eh.. i could see some things, like tsearch2 or pg_autovacuum, which
afaik are almost if not completely compatible with 7.3, which will not
get back ported. Also fixes in some of the extra tools like psql could
be very doable, I know I had a custom psql for 7.2 that back patched the
\timing
I would argue _very strongly_ against backporting features.
For massive features sure but an example of a feature that works
very well and easily with 7.3 is the preloading of libs.
Sincerely,
Joshua Drake
--
Co-Founder
Command Prompt, Inc.
The wheel's spinning but the hamster's dead
On Wed, 2003-10-01 at 09:41, Marc G. Fournier wrote:
On Wed, 1 Oct 2003, Robert Treat wrote:
Several linux distros already do this for many packages, and personally
I've always been surprised that, given postgresql's major release
upgrade issues, that no commercial company has stepped in
On Wed, Oct 01, 2003 at 08:49:51AM -0700, Joshua D. Drake wrote:
I would argue _very strongly_ against backporting features.
For massive features sure but an example of a feature that works
very well and easily with 7.3 is the preloading of libs.
Then let people patch the stable releases
On Wed, 2003-10-01 at 11:48, Joshua D. Drake wrote:
Sure but businesses don't like to upgrade unless they have too.
Granted, but maintaining old releases doesn't come at zero cost. It may
benefit some users, but the relevant question is whether that benefit is
worth the cost. The time someone
With 7.4 I'm finding upgrading to be easier. I'll likely upgrade out
production servers to 7.4.0 when it comes out and wind up skipping 7.3
altogether.
Sure but I talking about people who are running 7.3 and are happy with
it. The reality is that for probably 95% of the people
out there ,
Maybe I've mis-read Joshua's intentions, but I got the impression that
this 7.3 maintainer would follow the patches list and backport patches
whenever possible. This way folks coding for 7.4/7.5 can stay focused on
that, but folks who can't upgrade to 7.4 for whatever reason can still
get some
I don't believe anyone would work against this, nor could I imagine that
anyone would think it was a bad idea, I'm just curious as to how
possible it is to do ...
For most things probably not that possible. For things like:
Simple feature enhancements (preloading of libs)
Fixing pl/Language
Joshua D. Drake wrote:
For most things probably not that possible. For things like:
Simple feature enhancements (preloading of libs)
How long is a piece of string? When does something stop being simple?
Fixing pl/Language bugs (and making sure they still work on 7.3)
Buffer overflow fixes
On Wed, 1 Oct 2003, Joshua D. Drake wrote:
With 7.4 I'm finding upgrading to be easier. I'll likely upgrade out
production servers to 7.4.0 when it comes out and wind up skipping 7.3
altogether.
Sure but I talking about people who are running 7.3 and are happy with
it. The
then maybe they would be willing to donate some small amount each ($500 or
so) to pay for backporting issues. Since mostly what I'd want on an older
version would be bug / security fixes, that $500 should go a long way
towards backporting.
Sure.
I was under the imporession that 7.4
On Wed, Oct 01, 2003 at 11:53:12AM -0700, Joshua D. Drake wrote:
Eh? In 7.4 you should not need to reindex.
I thought tom was saying that the index bloat was better in 7.4 but it
was not gone... thus we would still need reindex yes?
The problem has been corrected enough for there to be no
On Wed, 2003-10-01 at 15:31, Joshua D. Drake wrote:
then maybe they would be willing to donate some small amount each ($500 or
so) to pay for backporting issues. Since mostly what I'd want on an older
version would be bug / security fixes, that $500 should go a long way
towards
and the question as i thought was being discussed (or should be
discussed) was what is the level of interest in having this work kept in
the community cvs tree vs. someone else's quasi-forked branch...
It is my thinking that regardless of commercial backing that the
PostgreSQL project as a
Joshua D. Drake [EMAIL PROTECTED] writes:
... having to reindex the database (which 7.4 doesn't fix),
It's supposed to fix it. What are you expecting not to be fixed?
regards, tom lane
---(end of broadcast)---
TIP 4:
Hello,
When I was reading hackers about the fixes you had made, it stated
that the index bloat problems should be better. I took
that as meaning that although it won't be required nearly as often, we
still may need to reindex occassionaly. It was later
pointed out to me that this may not be
Joshua D. Drake [EMAIL PROTECTED] writes:
When I was reading hackers about the fixes you had made, it stated
that the index bloat problems should be better. I took
that as meaning that although it won't be required nearly as often, we
still may need to reindex occassionaly.
The critical
Alvaro Herrera [EMAIL PROTECTED] writes:
I think what Tom is concerned about is that this hasn't been tested
enough with big datasets. Also there a little loss of index pages but
it's much less (orders of magnitude, I think) than what was before.
This is because the index won't shrink
Robert Treat [EMAIL PROTECTED] writes:
and the question as i thought was being discussed (or should be
discussed) was what is the level of interest in having this work kept in
the community cvs tree vs. someone else's quasi-forked branch...
I see no reason that the maintenance shouldn't be
Hello,
With the recent stint of pg_upgrade statements and the impending
release of 7.4 what
do people think about having a dedicated maintenance team for 7.3? 7.3
is a pretty
solid release and I think people will be hard pressed to upgrade to 7.4.
Of course
a lot of people will, but I have
62 matches
Mail list logo
