Added to TODO:
* Have VACUUM FULL use REINDEX rather than index vacuum
---
Alvaro Herrera wrote:
> On Sat, Oct 04, 2003 at 11:53:49PM -0400, Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > > Im
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 ridiculous
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
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
---(e
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 patch
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 gre
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 pop
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, a
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 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 i
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
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 wo
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
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
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 c
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
> > hea
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 a
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 tha
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
>
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: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
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.
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
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 VAC
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 i
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, p
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 al
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
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 pr
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 c
"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 consider
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 uplo
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
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
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 plausible.
> For example, if you have a timestamp index and you routinely clean out
> all entries older than N-days-ago, you won't have a problem in 7.4.
> If your pattern is to delete nine out of every ten entries (maybe you
> drop minute-by-minute entries and keep only hourly entries after awhile)
> then y
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 b
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 "v
"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 cr
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 th
"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:
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 wh
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 b
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
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 removed
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
>
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
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
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 fea
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 , t
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 sp
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 release
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 step
> 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
-
> 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
> \timin
On Tue, Sep 30, 2003 at 09:37:26AM -0700, Joshua D. Drake wrote:
>
> Of course the theory being that we backport "some" features and fix
> any bugs that
> we find?
I would argue _very strongly_ against backporting features.
The backporting of features into the Linux kernel is an extremely
good
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
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 u
"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, t
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
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 upg
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 p
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 upgrad
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 cus
65 matches
Mail list logo
