Thread: 7.4?
Do you guys have any tentative estimates about when 7.4 is going to get released? What is the timeframe? Also, what is going to be there that is not in 7.3? I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to wait for 7.4 and go rightthere... Thanks! Dima
If it ain't broke, don't fix it! 2/24/2003 11:36:33 AM, Dmitry Tkach <dmitry@openratings.com> wrote: > >Do you guys have any tentative estimates about when 7.4 is going to get released? >What is the timeframe? Also, what is going to be there that is not in 7.3? >I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to wait for 7.4 and go right there... > >Thanks! > >Dima > > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > >http://archives.postgresql.org >
Dennis Gearon wrote: >If it ain't broke, >don't fix it! > Yeah... I know. That's exactly where I am coming from :-) I am sitting on about a 200G database here, and I know what a pain in the neck it is going to be to migrate it (plus, I've got some "C" functions, that, as I figured recently do not even compile with 7.3) :-( But there is some stuff in 7.3 that I really miss - like function returning tuples, prepared and saved query plans, vacuum (full) behaviour etc... Besides, Tom Lane has said some really scarry things about possible data corruption/loss stuff in 7.2... So, it sounds like I am going to have to go through this upgrade nightmare... the only question is - when it is a good time to do it... Dima > >2/24/2003 11:36:33 AM, Dmitry Tkach <dmitry@openratings.com> wrote: > > > >>Do you guys have any tentative estimates about when 7.4 is going to get released? >>What is the timeframe? Also, what is going to be there that is not in 7.3? >>I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to >> >> >wait for 7.4 and go right there... > > >>Thanks! >> >>Dima >> >> >>---------------------------(end of broadcast)--------------------------- >>TIP 6: Have you searched our list archives? >> >>http://archives.postgresql.org >> >> >> > > > >
On Mon, Feb 24, 2003 at 14:36:33 -0500, Dmitry Tkach <dmitry@openratings.com> wrote: > > Do you guys have any tentative estimates about when 7.4 is going to get > released? > What is the timeframe? Also, what is going to be there that is not in 7.3? > I am currently on 7.2, and trying to find out whether it makes sense to > upgrade to 7.3 now or to wait for 7.4 and go right there... My opinion is that you should go to 7.3 now. 7.4 seems to have a ways to go before it is even going to be in beta, so it will be a minimum of several months before it is released. The change from 7.3 to 7.4 will likely be easier than going from 7.2 to 7.3 (because schemas are a big change in 7.3).
Could someone summarize what would be the 3 changes that would have the most impact in 7.4? - Ericson Smith eric@did-it.com On Mon, 2003-02-24 at 14:05, Bruno Wolff III wrote: > On Mon, Feb 24, 2003 at 14:36:33 -0500, > Dmitry Tkach <dmitry@openratings.com> wrote: > > > > Do you guys have any tentative estimates about when 7.4 is going to get > > released? > > What is the timeframe? Also, what is going to be there that is not in 7.3? > > I am currently on 7.2, and trying to find out whether it makes sense to > > upgrade to 7.3 now or to wait for 7.4 and go right there... > > My opinion is that you should go to 7.3 now. > > 7.4 seems to have a ways to go before it is even going to be in beta, so it > will be a minimum of several months before it is released. > > The change from 7.3 to 7.4 will likely be easier than going from > 7.2 to 7.3 (because schemas are a big change in 7.3). > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster -- Ericson Smith <eric@did-it.com>
On Mon, 2003-02-24 at 14:29, Ericson Smith wrote: > Could someone summarize what would be the 3 changes that would have the > most impact in 7.4? > Impact to who? :-) 1. Native Windows Support 2. Point In Time Recovery 3. Standard Replication Solution (Please note that while these are all currently planned for 7.4, and are actively being developed, I can't guarantee they will all be there.) Robert Treat
On 24 Feb 2003, Ericson Smith wrote: > Could someone summarize what would be the 3 changes that would have the > most impact in 7.4? I would say the biggest impact from 7.2 to 7.3 are: - Schemas and their support - Indexing issues related to using C locale or anything else - The less greedy type matching changes result in some indexes being ignored that were once used. - Old sequences and other things won't inherit dependency. not a real problem, just an fyi. From 7.3 to 7.4 the biggest changes planned so far: - windows native support <-- gartner gives it a 90% chance of making it into the main disto... :-) - fix for in() performance issue <-- already in CVS tip - partitioning or tablespaces <-- who know? seriously, who? - vacuum will be able to compact out unused space <-- Tom Lane - possible newer settings for the default postgresql.conf could increase load on some machines to a point they may need to be reconfigured to come up. Data wise I don't think there's gonna be a lot that will mess up a 7.3 to 7.4 conversion so far that's gone by.
> From 7.3 to 7.4 the biggest changes planned so far: > - windows native support <-- gartner gives it a 90% chance of making it > into the main disto... :-) > - fix for in() performance issue <-- already in CVS tip > - partitioning or tablespaces <-- who know? seriously, who? > - vacuum will be able to compact out unused space <-- Tom Lane Will we be able to run the new vacuum system without locking the tables? Currently our database is at about 15gigs. Over the period of a month, it grows to about 25gigs (10Gb wasted space). Every month we have a cleanup routine which involves copying the most actively updated tables to text, and importing the data again. We vacuum every night and analyze 4 times per day, but we're loath to do a VACUUM FULL because of the table locking issues (locking some of the tables would break the operation of some of our 24/7 systems), hence we prefer to stop the db about once per month, eat the downtime as scheduled (about 1.5 hours), and get back to business for the next 30 days again. We're all behind Tom on this change :-) - Ericson Smith eric@did-it.com -- Ericson Smith <eric@did-it.com>
Dmitry Tkach <dmitry@openratings.com> writes:
> I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to wait for 7.4 and go
rightthere...
And when 7.4 is out, won't you be wondering whether to wait for 7.5?
I'd say update when the current version seems worth the effort of
updating to you. Don't think about the future, or you'll be chasing
mirages forever.
Anyway, to answer your question: the current timeframe for 7.4 beta is
April-ish. Sometime after that it will go final. Sometime after
*that*, a prudent DBA might think about migrating to it. How long do
you want to wait?
regards, tom lane
On Mon, 2003-02-24 at 12:28, Robert Treat wrote: > On Mon, 2003-02-24 at 14:29, Ericson Smith wrote: > > Could someone summarize what would be the 3 changes that would have the > > most impact in 7.4? > > > > Impact to who? :-) > > 1. Native Windows Support > 2. Point In Time Recovery > 3. Standard Replication Solution #3 is a very big deal for business users. I am very glad to hear it is in 7.4. Point in time recovery is also an important thing for biz users.
How about auto-vacuum.... Robert Treat wrote: >On Mon, 2003-02-24 at 14:29, Ericson Smith wrote: > > >>Could someone summarize what would be the 3 changes that would have the >>most impact in 7.4? >> >> >> > >Impact to who? :-) > >1. Native Windows Support >2. Point In Time Recovery >3. Standard Replication Solution > >(Please note that while these are all currently planned for 7.4, and are >actively being developed, I can't guarantee they will all be there.) > >Robert Treat > > > >---------------------------(end of broadcast)--------------------------- >TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/users-lounge/docs/faq.html > >
On 24 Feb 2003, Ericson Smith wrote: > > > From 7.3 to 7.4 the biggest changes planned so far: > > - windows native support <-- gartner gives it a 90% chance of making it > > into the main disto... :-) > > - fix for in() performance issue <-- already in CVS tip > > - partitioning or tablespaces <-- who know? seriously, who? > > - vacuum will be able to compact out unused space <-- Tom Lane > > Will we be able to run the new vacuum system without locking the tables? Vacuum only locks the tables now for a second or so. You might want to look at using regular vacuums more often. In my testing, vacuum (non full) uses <2% of the CPU on a heavily loaded server. Between the low load of vacuum and having higher fsm settings, you might obviate the need to regular vacuum any more than once a day or week or whatever.
Hi all, I am having trouble reindexing our DB. We are running PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.1 backend> reindex database evolvo force NOTICE: relation 1247 was reindexed NOTICE: relation 1249 was reindexed NOTICE: relation 1259 was reindexed NOTICE: relation 1261 was reindexed NOTICE: relation 1262 was reindexed ERROR: cannot create pg_inherits_relid_seqno_index: File exists Can someone help me. Thanks Andrew Bartley
On Mon, Feb 24, 2003 at 03:53:14PM -0500, Ericson Smith wrote:
>
> Will we be able to run the new vacuum system without locking the tables?
I believe the new vacuum stuff is just to help on btree indexes. The
current vacuum doesn't lock the tables, either.
> Currently our database is at about 15gigs. Over the period of a month,
> it grows to about 25gigs (10Gb wasted space). Every month we have a
> cleanup routine which involves copying the most actively updated tables
> to text, and importing the data again. We vacuum every night and analyze
> 4 times per day, but we're loath to do a VACUUM FULL because of the
> table locking issues (locking some of the tables would break the
It sounds like either your free space map is not set correctly, or
you have ever-growing indexes. Reindexing would be enough for this
problem. There are still some 24/7-operation problems with having to
reindex.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Mon, Feb 24, 2003 at 04:12:41PM -0500, Tom Lane wrote:
> April-ish. Sometime after that it will go final. Sometime after
> *that*, a prudent DBA might think about migrating to it. How long do
This is a good point: 7.3 (i.e. with no dot-release) was a bad bet
for production use, because of the numbers of changes in the system;
PITR alone will require enough changes that I wouldn't trust it for
production use immediately. Just because the software has been
released doesn't mean it's ready to put everywhere yet, especially
when you consider that dropping back a version is not something
really contemplated by the current upgrade path.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Tue, 2003-02-25 at 08:18, Andrew Sullivan wrote: > I believe the new vacuum stuff is just to help on btree indexes. The > current vacuum doesn't lock the tables, either. I was actually thinking about a VACUUM FULL. Currently we have not problems doing a regular VACUUM. That said, will the new vacuum free as much space like the current vacuum full, without the handicap of table locking? > It sounds like either your free space map is not set correctly, or > you have ever-growing indexes. Reindexing would be enough for this > problem. There are still some 24/7-operation problems with having to > reindex. > We will definitely try the reindex as suggested. -- Ericson Smith <eric@did-it.com>
On Tue, Feb 25, 2003 at 09:41:13AM -0500, Ericson Smith wrote:
> I was actually thinking about a VACUUM FULL. Currently we have not
VACUUM FULL will always block. To make a rather nasty comparison,
it's like defragging your disk under Windows: you can't really access
a file which is being moved around.
> problems doing a regular VACUUM. That said, will the new vacuum free as
> much space like the current vacuum full, without the handicap of table
> locking?
Yes and no. VACUUM FULL recovers space absolutely. So if you know
that the table has really shrunk, and shrunk permanently (or similar
cases, like 100% of the table was replaced), then you need VACUUM
FULL. Non-blocking VACUUM will make the freed space available to
Postgres, but not to the filesystem in general. In other words, the
regular VACUUM should mean that your table size stabilises, given
that your database is always more or less the same number of tuples;
but it will be slightly larger on disk than that number of tuples
strictly requires. (Is that clear? If not, maybe someone else can
make it clearer.)
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
"Andrew Bartley" <abartley@evolvosystems.com> writes:
> We are running PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC gcc
> (GCC) 3.2.1
> backend> reindex database evolvo force
> NOTICE: relation 1247 was reindexed
> NOTICE: relation 1249 was reindexed
> NOTICE: relation 1259 was reindexed
> NOTICE: relation 1261 was reindexed
> NOTICE: relation 1262 was reindexed
> ERROR: cannot create pg_inherits_relid_seqno_index: File exists
If you've been running this database long enough to wrap around the OID
counter, then this failure is possible (though I wouldn't have thought
it probable). Try a few times and it'll probably succeed eventually.
regards, tom lane
On Mon, 2003-02-24 at 15:28, Robert Treat wrote: > 3. Standard Replication Solution I'd be quite surprised to see this in 7.4. Not that I wouldn't love to have someone contribute it -- I just wouldn't bet on it being in 7.4 if the beta date is around the middle of April. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
On Sat, 2003-02-22 at 07:56, Joe Tomcat wrote: > On Mon, 2003-02-24 at 12:28, Robert Treat wrote: > > On Mon, 2003-02-24 at 14:29, Ericson Smith wrote: > > > Could someone summarize what would be the 3 changes that would have the > > > most impact in 7.4? > > > > > > > Impact to who? :-) > > > > 1. Native Windows Support > > 2. Point In Time Recovery > > 3. Standard Replication Solution > > #3 is a very big deal for business users. I am very glad to hear it is > in 7.4. Point in time recovery is also an important thing for biz > users. > For the record let me re-emphasize that none of these are guaranteed to be in 7.4. They are all actively being worked on, and the current hopes of the developers is that they will all be in, but it is quite possible that one of these might not make it in (and most likely to not make would be replication imho) Robert Treat
Neil Conway writes: > I'd be quite surprised to see this in 7.4. Not that I wouldn't love to > have someone contribute it -- I just wouldn't bet on it being in 7.4 if > the beta date is around the middle of April. When someone says that beta is planned April-ish, that means beta will be in June and the final release will be in September. Mark my words. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> Neil Conway writes:
>> I'd be quite surprised to see this in 7.4. Not that I wouldn't love to
>> have someone contribute it -- I just wouldn't bet on it being in 7.4 if
>> the beta date is around the middle of April.
> When someone says that beta is planned April-ish, that means beta will be
> in June and the final release will be in September. Mark my words.
If all three of these changes (Windows port, pitr, replication) get in
before feature freeze, I wouldn't want to bet that final will be any
sooner than that --- we'll have lots of testing to do.
But we *will* freeze 7.4 features in April, and at the rate work appears
to be progressing, I wouldn't want to bet that any of these features
will be in by then ;-). If they don't make the cut, 7.4 final will
probably be a lot sooner than September.
regards, tom lane
On Tuesday February 25 2003 10:30, Robert Treat wrote: > On Sat, 2003-02-22 at 07:56, Joe Tomcat wrote: > > On Mon, 2003-02-24 at 12:28, Robert Treat wrote: > > > On Mon, 2003-02-24 at 14:29, Ericson Smith wrote: > > > > Could someone summarize what would be the 3 changes that > > > > would have the most impact in 7.4? > > >... > > > 3. Standard Replication Solution > > > > #3 is a very big deal for business users. I am very glad to hear > > it is in 7.4.... > > For the record let me re-emphasize that none of these are > guaranteed to be in 7.4. They are all actively being worked on, > and the current hopes of the developers is that they will all be > in, but it is quite possible that one of these might not make it in > (and most likely to not make would be replication imho) And do I understand correctly the replication to be eventually included will be an embedded syncronous replication solution based on Postgres-R and the Spread GCS? I'm asking because we have need for an *asyncronous*, non-embedded solution, and would like to stay on the beaten path if possible. Ed
On Tue, 2003-02-25 at 22:44, Ed L. wrote: > And do I understand correctly the replication to be eventually > included will be an embedded syncronous replication solution based on > Postgres-R and the Spread GCS? No, I don't think that's set in stone (although I can't speak for the core team). While I think Postgres-R is promising, there might be room for additional replication implementations that cater to different sets of requirements. IMHO, eventually providing solutions for both synchronous and asynchronous replication would be a good idea. Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway <neilc@samurai.com> writes:
> On Tue, 2003-02-25 at 22:44, Ed L. wrote:
>> And do I understand correctly the replication to be eventually
>> included will be an embedded syncronous replication solution based on
>> Postgres-R and the Spread GCS?
> No, I don't think that's set in stone (although I can't speak for the
> core team). While I think Postgres-R is promising, there might be room
> for additional replication implementations that cater to different sets
> of requirements.
There absolutely *is* room for multiple replication implementations.
AFAICS there's no one-size-fits-all approach. I did and still do like
Postgres-R as a pretty useful approach, but it should not be mistaken
for The One True Path.
Also, there are nontrivial licensing issues involved. The PG-R design
depends on an underlying "group communication" system, which is a
nontrivial bit of software that none of the core team wants to rewrite.
But none of the available GC systems are BSD-license open source. We
had had some hopes of getting Spread to offer BSD terms, but that seems
to have fallen through. So right now, PG-R is on the outside looking
in, as far as inclusion in the core distribution goes :-(
regards, tom lane
On Tuesday February 25 2003 11:52, Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > On Tue, 2003-02-25 at 22:44, Ed L. wrote: > >> And do I understand correctly the replication to be eventually > >> included will be an embedded syncronous replication solution > >> based on Postgres-R and the Spread GCS? > > > > No, I don't think that's set in stone (although I can't speak for > > the core team). While I think Postgres-R is promising, there > > might be room for additional replication implementations that > > cater to different sets of requirements. > > There absolutely *is* room for multiple replication > implementations. AFAICS there's no one-size-fits-all approach. I > did and still do like Postgres-R as a pretty useful approach, but > it should not be mistaken for The One True Path. That's good to hear. We're looking for an asyncronous, non-embedded, master-slave replication solution. Among 7 pgsql replication projects I've reviewed lately, the best prospects right now appear to be rserv (testing it now) or failing that, some enhancements to DBMirror. Is there any near consensus among the core developers on the best open source asyncronous solution as of today? Ed
On Tuesday February 25 2003 11:52, Tom Lane wrote: > > Also, there are nontrivial licensing issues involved. The PG-R > design depends on an underlying "group communication" system, which > is a nontrivial bit of software that none of the core team wants to > rewrite. But none of the available GC systems are BSD-license open > source. We had had some hopes of getting Spread to offer BSD > terms, but that seems to have fallen through. So right now, PG-R > is on the outside looking in, as far as inclusion in the core > distribution goes :-( Is anyone aware of particular reasons why the group is pushing on a syncronous solution? I'm sure they have good reasons, but I would've assumed an asyncronous solution would be far more applicable for simple redundancy as opposed to syncronicity for high-performance clusters, not too mention being far simpler implementations. Ed
On Tue, 2003-02-25 at 23:53, Ed L. wrote: > On Tuesday February 25 2003 11:52, Tom Lane wrote: > > > > Also, there are nontrivial licensing issues involved. The PG-R > > design depends on an underlying "group communication" system, which > > is a nontrivial bit of software that none of the core team wants to > > rewrite. But none of the available GC systems are BSD-license open > > source. We had had some hopes of getting Spread to offer BSD > > terms, but that seems to have fallen through. So right now, PG-R > > is on the outside looking in, as far as inclusion in the core > > distribution goes :-( > > Is anyone aware of particular reasons why the group is pushing on a > syncronous solution? I'm sure they have good reasons, but I would've > assumed an asyncronous solution would be far more applicable for > simple redundancy as opposed to syncronicity for high-performance > clusters, not too mention being far simpler implementations. Some business needs absolutely must have synchronus replication. You're right that most users want async so they can have clusters serving data out, but there are some very good reasons for sync: 1. Financial transactions MUST have off-site sync replication. 2. If you have a cluster of servers, sync guarantees that all the data are in a consistent state. Ease of administration and reliability may be worth the slight performance penalty. 3. For servers on a fast LAN, sync may not make much of a difference on performance. I personally think that sync should be used in more cases than is generally thought. We can get very reliable LANs and even WAN links, and if I know that the data are always consistent, that makes my life much much easier than having to worry about cases where they are not.
Le Mercredi 26 Février 2003 07:52, Tom Lane a écrit : > Neil Conway <neilc@samurai.com> writes: > > On Tue, 2003-02-25 at 22:44, Ed L. wrote: > >> And do I understand correctly the replication to be eventually > >> included will be an embedded syncronous replication solution based on > >> Postgres-R and the Spread GCS? > > > > No, I don't think that's set in stone (although I can't speak for the > > core team). While I think Postgres-R is promising, there might be room > > for additional replication implementations that cater to different sets > > of requirements. > > There absolutely *is* room for multiple replication implementations. > AFAICS there's no one-size-fits-all approach. I did and still do like > Postgres-R as a pretty useful approach, but it should not be mistaken > for The One True Path. > > Also, there are nontrivial licensing issues involved. The PG-R design > depends on an underlying "group communication" system, which is a > nontrivial bit of software that none of the core team wants to rewrite. > But none of the available GC systems are BSD-license open source. We > had had some hopes of getting Spread to offer BSD terms, but that seems > to have fallen through. So right now, PG-R is on the outside looking > in, as far as inclusion in the core distribution goes :-( > > regards, tom lane You mean the PG-R project will no be included in the PostgreSQL project unless someone rewrite the Spread GCS concept or similar system in a BSD licence ? What a bad news for the community ... ! :o( PG-R seems to be the best integrated solution of the moment ... Still a lot of work ... but Darren and others are making a real good job ! DBMirror or rserv (commercial application) seems to be only triggers, and little demon not included in PostgreSQL system ... as PG-R is ... PostgreSQL really need an official Replication solution to be definitively secured in a productive environnement ... and I think I'm not the only one thinking like that ... looking the survey of Postgres.org web site : http://www.postgresql.org/survey.php?View=1&SurveyID=9 -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Tel. 33-144949901 fax. 33-144949902
could anyone send me an example of CREATE FINTION using 'plpgsql' as language and using paramters (more then 1)? please I don't know how to manipulate the params into the function... TIA Roberto de Amorim
"Ed L." <pgsql@bluepolka.net> writes:
> Is anyone aware of particular reasons why the group is pushing on a
> syncronous solution? I'm sure they have good reasons, but I would've
> assumed an asyncronous solution would be far more applicable for
You're just showing bias in the other direction ;-).
Back when I was working for Great Bridge and got to spend a fair amount
of time at trade shows talking to potential customers, the thing we
heard over and over again was that people wanted multiple servers for
reliability/redundancy. That goal seems to me to be best served by a
symmetric multi-master configuration, which is difficult if not
impossible to do with async replication.
There are certainly plenty of other scenarios where async works as well
or better, but that one seemed to be where the market was, at least in
terms of the presence of customers who might be willing to pay to have
it developed. So that's what the ex-Great-Bridgers among core have been
thinking about doing first. Also, there already is a credible async
replication alternative (PostgreSQL Inc's erserv), so filling the vacuum
for a sync solution seems higher-priority than doing another async
solution.
regards, tom lane
=?iso-8859-15?q?Herv=E9=20Piedvache?= <herve@elma.fr> writes:
> Le Mercredi 26 F�vrier 2003 07:52, Tom Lane a �crit :
>> But none of the available GC systems are BSD-license open source. We
>> had had some hopes of getting Spread to offer BSD terms, but that seems
>> to have fallen through. So right now, PG-R is on the outside looking
>> in, as far as inclusion in the core distribution goes :-(
> You mean the PG-R project will no be included in the PostgreSQL project
> unless someone rewrite the Spread GCS concept or similar system in a BSD
> licence ?
Well, we certainly won't be bundling Spread into the distribution if
it's not got a compatible license. I had originally hoped that the
PG-R project would end by having a complete sync replication solution
included in the standard PG distribution, but that goal is looking out
of reach at the moment.
regards, tom lane
On Wednesday 26 February 2003 12:55, Roberto de Amorim wrote: > could anyone send me an example of CREATE FINTION using 'plpgsql' as > language and using paramters (more then 1)? > please > > I don't know how to manipulate the params into the function... > See: http://developer.postgresql.org/docs/postgres/plpgsql-examples.html
On Wednesday February 26 2003 3:55, Hervé Piedvache wrote: > > PG-R seems to be the best integrated solution of the moment ... > Still a lot of work ... but Darren and others are making a real > good job ! > > DBMirror or rserv (commercial application) seems to be only > triggers, and little demon not included in PostgreSQL system ... as > PG-R is ... Remember there are distinct needs for both syncronous and asyncronous solutions. PG-R is a *syncronous* solution. Solutions like DBMirror, rserv, and eRServer, on the other hand, are asyncronous solutions and thus have a complimentary role. Ed
How about a feature as in Informix where you could specify a database_id where then thru a realm.conf file you map that id to a hostname:databasename then saying database.schema.table mapps to hostname.database.schema.table This way the applications can do a bit HA or distributed DB... Neil Conway wrote: >On Tue, 2003-02-25 at 22:44, Ed L. wrote: > > >>And do I understand correctly the replication to be eventually >>included will be an embedded syncronous replication solution based on >>Postgres-R and the Spread GCS? >> >> > >No, I don't think that's set in stone (although I can't speak for the >core team). While I think Postgres-R is promising, there might be room >for additional replication implementations that cater to different sets >of requirements. > >IMHO, eventually providing solutions for both synchronous and >asynchronous replication would be a good idea. > >Cheers, > >Neil > >
On Wednesday February 26 2003 8:08, Tom Lane wrote: > > I would've assumed an asyncronous solution would be far more > > applicable for > > You're just showing bias in the other direction ;-). Mea culpa. > Back when I was working for Great Bridge and got to spend a fair > amount of time at trade shows talking to potential customers, the > thing we heard over and over again was that people wanted multiple > servers for reliability/redundancy. That goal seems to me to be > best served by a symmetric multi-master configuration, which is > difficult if not impossible to do with async replication. I also share the objectives of reliability/redundancy. My concern with syncronous solutions in general is recoverability when one of two masters fails. Admittedly at the price of intervals of data inconsistency between master and slave, async solutions can just pop back online and "catch-up", thus the appeal. In reading a little more on PG-R, I understand the use of the Spread GCS would seem to address that recoverability concern along with performance concerns. Is that your understanding? As an aside, ERserver looks credible, though the $10,000 pricetag and closed source are somewhat of a barrier, so I hope an increasingly useful open-source async solution can further emerge. Ed
On Wed, 2003-02-26 at 07:08, Tom Lane wrote: > Back when I was working for Great Bridge and got to spend a fair amount > of time at trade shows talking to potential customers, the thing we > heard over and over again was that people wanted multiple servers for > reliability/redundancy. That goal seems to me to be best served by a > symmetric multi-master configuration, which is difficult if not > impossible to do with async replication. I'm glad to hear that PG is heading in that direction. Think of it this way: the entire reason we use databases instead of a mess of text files is because of the benefits we get in terms of data consistency. ACID forms the foundation for a reliable service, whether it's financial transactions or a chat room. It is difficult or impossible to maintain ACID in an async situation, I believe. Sync is actually much more useful because it lets a business have a cluster of servers without having to worry about what state things are in.
On 24 Feb 2003 04:00:51 -0800 Joe Tomcat <tomcat@mobile.mp> wrote:
> Sync is actually much more useful because it lets a business have a
> cluster of servers without having to worry about what state things are
> in.
sync is more useful _if_ sync is what you need.
my current project needs async, sync wouldn't help me a damn bit.
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Unix, Linux, IP Network Engineering, Security
On 24 Feb 2003 at 15:53, Ericson Smith wrote: > Currently our database is at about 15gigs. Over the period of a month, > it grows to about 25gigs (10Gb wasted space). Every month we have a > cleanup routine which involves copying the most actively updated tables > to text, and importing the data again. We vacuum every night and analyze > 4 times per day, but we're loath to do a VACUUM FULL because of the > table locking issues (locking some of the tables would break the > operation of some of our 24/7 systems), hence we prefer to stop the db > about once per month, eat the downtime as scheduled (about 1.5 hours), > and get back to business for the next 30 days again. We ahd a discussion on this few days back and the solution might work as well for you(apart from suggestions you have already received). Instead of vacuum full on a table, backup the table to a dump file, drop it and recreate it. It takes more efforts than simple vacuum full but may run much faster if you have large amount of space to recover. Try it. Bye Shridhar -- "I'd crawl over an acre of 'Visual This++' and 'Integrated DevelopmentThat' to get to gcc, Emacs, and gdb. Thank you."(By Vance Petree, Virginia Power)
At 08:07 27.02.03, you wrote:
>On 24 Feb 2003 at 15:53, Ericson Smith wrote:
> > Currently our database is at about 15gigs. Over the period of a month,
> > it grows to about 25gigs (10Gb wasted space). Every month we have a
> > cleanup routine which involves copying the most actively updated tables
> > to text, and importing the data again. We vacuum every night and analyze
> > 4 times per day, but we're loath to do a VACUUM FULL because of the
> > table locking issues (locking some of the tables would break the
> > operation of some of our 24/7 systems), hence we prefer to stop the db
> > about once per month, eat the downtime as scheduled (about 1.5 hours),
> > and get back to business for the next 30 days again.
>
>We ahd a discussion on this few days back and the solution might work as well
>for you(apart from suggestions you have already received).
>
>Instead of vacuum full on a table, backup the table to a dump file, drop
>it and
>recreate it. It takes more efforts than simple vacuum full but may run much
>faster if you have large amount of space to recover.
>
> Try it.
It was me having this problem with our DB, although it only went to 1 gig
for some
3000 rows overall. So far, the problem is not really solved for me, since
vacuum full
simply takes far too long to clean up the DB. Disksize of this DB varies around
800 MB to 1 Gig and a vacuum full 'only' takes it down to 500 megs.
A complete dump and re-creation of the dbase creates a nice 120 megs DB.
Shouldnt a 'vacuum full' come close to this ? atleast not 4-5 times the size.
Our problems are caused by a popular (?) bannersystem, btw, which simply does
too many updates. (A few on each user request to the webserver).
(The very same bannersystem exists for MySQL and the table there is less
than a megabyte. We switched to MySQL after one of the servers couldnt
stand the load
anymore. Another Server is still running the pg version, but mainly for
testing purposes and
to help out the dude who is porting it to pg ...)
I also want to add, that postgres' "contrib/vacuumlo" didnt change much on the
large DB and a load of changes on that bannersystem didn't do much either.
l8r
Andreas Rust - webnova GmbH
rust@webnova.de - www.webnova.de
Tel: +49 (0)234 - 912 96 10
Fax: +49 (0)234 - 912 96 15
+:----------------------------------------------------------:+
Internet Solutions & Creative Design
I looked at http://developer.postgresql.org/docs/postgres/plpgsql-examples.html but there is not an example of function returning more then 1 value... could anyone sand me an example of function returning more then 1 value using PLPGSQL ? please TIA Roberto de amorim
On Thursday 27 February 2003 12:25, Roberto de Amorim wrote: > I looked at > http://developer.postgresql.org/docs/postgres/plpgsql-examples.html > but there is not an example of function returning more then 1 value... > > could anyone sand me an example of function returning more then 1 value > using PLPGSQL ? please > You can't return more than one return value from function, but that value can be of composite type.For example :"setof text" or "setof record" are such types. See: http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html http://developer.postgresql.org/docs/postgres/xfunc.html Regards !
On Wed, Feb 26, 2003 at 02:41:10PM -0700, Ed L. wrote:
> I also share the objectives of reliability/redundancy. My concern
> with syncronous solutions in general is recoverability when one of
> two masters fails. Admittedly at the price of intervals of data
> inconsistency between master and slave, async solutions can just pop
> back online and "catch-up", thus the appeal. In reading a little
It seems to me that this answer is only true if you can tolerate loss
or delay of transactions. That is, if the order of transactions
matters, you really can't just make your former slave a master
without knowing that the failed master has sent everything to the
slave.
If order matters, then the opposite is true: because you know that
any master has all the data, you can just accept it when one master
goes away. Of course, that requires a good program for adding new
replicated systems, which I guess is what Postgres-R is going to do.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Thu, 27 Feb 2003, Shridhar Daithankar wrote: > On 24 Feb 2003 at 15:53, Ericson Smith wrote: > > Currently our database is at about 15gigs. Over the period of a month, > > it grows to about 25gigs (10Gb wasted space). Every month we have a > > cleanup routine which involves copying the most actively updated tables > > to text, and importing the data again. We vacuum every night and analyze > > 4 times per day, but we're loath to do a VACUUM FULL because of the > > table locking issues (locking some of the tables would break the > > operation of some of our 24/7 systems), hence we prefer to stop the db > > about once per month, eat the downtime as scheduled (about 1.5 hours), > > and get back to business for the next 30 days again. > > We ahd a discussion on this few days back and the solution might work as well > for you(apart from suggestions you have already received). > > Instead of vacuum full on a table, backup the table to a dump file, drop it and > recreate it. It takes more efforts than simple vacuum full but may run much > faster if you have large amount of space to recover. Another option is to do something like: begin; select * into temp_table from bigtable; delete from big_table; insert into big_table (select * from temp_table); commit; This way your table is online while you're doing this, and can still be selected by various clients without interruption.
On Thursday February 27 2003 6:36, Andrew Sullivan wrote: > On Wed, Feb 26, 2003 at 02:41:10PM -0700, Ed L. wrote: > > I also share the objectives of reliability/redundancy. My > > concern with syncronous solutions in general is recoverability > > when one of two masters fails. Admittedly at the price of > > intervals of data inconsistency between master and slave, async > > solutions can just pop back online and "catch-up", thus the > > appeal. In reading a little > > It seems to me that this answer is only true if you can tolerate > loss or delay of transactions. That is, if the order of > transactions matters, you really can't just make your former slave > a master without knowing that the failed master has sent everything > to the slave. Agreed. In our case, we presently have _no_ replication solution nor do we have a true file system snapshot capability e.g. NetApp. So, in the event of the untimely total demise of the primary server, the timespan of data loss equals time since the last dump that made it off the server. That typically amounts to _hours_. With async replication to a spare server, that couple of hours of lost data would seem to be reduced to seconds. That's not ideal by any stretch, but is a monstrous improvement. I'm assuming eRServer, rserv, or DBMirror maintains a proper transaction order, even if it's incomplete. > If order matters, then the opposite is true: because you know that > any master has all the data, you can just accept it when one master > goes away. Of course, that requires a good program for adding new > replicated systems, which I guess is what Postgres-R is going to > do. Agreed. It also requires a good program for dealing with failed masters and dealing with sync performance issues (2-phase commit). Sounds like PG-R + Spread is tackling that, too. I am learning that, if PG-R can work as advertised, it removes all my concerns about a syncronous system. My current thinking is to implement simple async master/slave now, with the acknowledged potential data loss (albeit much smaller), and migrate to sync multi-master if/when PG-R comes online. I had little success with rserv, but DBMirror worked ok. I'm enhancing DBMirror up to work better for our environment. Ed
On Thu, 27 Feb 2003 12:00:50 -0700 "Ed L." <pgsql@bluepolka.net> wrote:
> I had little
> success with rserv, but DBMirror worked ok. I'm enhancing DBMirror
> up to work better for our environment.
this actually brings up a question:
is there currently a mailing list for DBMirror users? i'm about to start
using it, and a place to discuss it with other users might be a useful
subgroup.
if not, i can certainly set one up on my server, although there might be
more appropriate places for one to be set up (e.g., on postgresql.org)
richard
--
Richard Welty rwelty@averillpark.net
Averill Park Networking 518-573-7592
Unix, Linux, IP Network Engineering, Security
On Thu, Feb 27, 2003 at 12:00:50PM -0700, Ed L. wrote:
> stretch, but is a monstrous improvement. I'm assuming eRServer,
> rserv, or DBMirror maintains a proper transaction order, even if it's
> incomplete.
I dunno about dbmirror, but rserv and its bigger cousin both actually
apply the current-as-of-snapshot version of the row (which means that
if you have multiple changes to the same row, you needn't go through
all the iterations when applying the snapshot). I presume the same
is true of dbmirror, since it relies on the primary key.
> Sounds like PG-R + Spread is tackling that, too. I am learning that,
> if PG-R can work as advertised, it removes all my concerns about a
> syncronous system.
Yes, if it works as advertised, it'd be a _mighty sweet_ piece of
technology.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Thursday February 27 2003 12:57, Andrew Sullivan wrote: > > I dunno about dbmirror, but rserv and its bigger cousin both > actually apply the current-as-of-snapshot version of the row (which > means that if you have multiple changes to the same row, you > needn't go through all the iterations when applying the snapshot). > I presume the same is true of dbmirror, since it relies on the > primary key. Unfortunately, dbmirror does go through all the iterations, even if there is no net change. That current-as-of-snapshot capability you describe would be a very useful enhancement. Ed
On Thursday February 27 2003 12:56, Richard Welty wrote:
>
> is there currently a mailing list for DBMirror users? i'm about to
> start using it, and a place to discuss it with other users might be
> a useful subgroup.
No comment on a new mailing list, but I'm happy to collaborate if
there is interest. The key changes in which I'm presently interested
are:
* master/slave port specification (done);
* configurable sync delay (done);
* "current-as-of-snapshot" described by Andrew Sullivan;
* tools for easy setup and activation;
* multi-slave;
Ed
On Thu, Feb 27, 2003 at 02:21:23PM -0700, Ed L. wrote:
>
> Unfortunately, dbmirror does go through all the iterations, even if
So does dbmirror keep a copy of the row somewhere? Doesn't that add
a lot to i/o?
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Thu, Feb 27, 2003 at 02:56:33PM -0500, Richard Welty wrote:
> is there currently a mailing list for DBMirror users? i'm about to start
There has been some discussion about it on the replication list. The
replication list is pretty low-traffic, and it's a natural place to
discuss it.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Thursday February 27 2003 2:21, Ed L. wrote: > On Thursday February 27 2003 12:57, Andrew Sullivan wrote: > > I dunno about dbmirror, but rserv and its bigger cousin both > > actually apply the current-as-of-snapshot version of the row > > (which means that if you have multiple changes to the same row, > > you needn't go through all the iterations when applying the > > snapshot). I presume the same is true of dbmirror, since it > > relies on the primary key. By the way, rserv failed precisely in this case for me as I mentioned in a previous recent post. Ed
On Thursday February 27 2003 3:28, Andrew Sullivan wrote: > On Thu, Feb 27, 2003 at 02:21:23PM -0700, Ed L. wrote: > > Unfortunately, dbmirror does go through all the iterations, even > > if > > So does dbmirror keep a copy of the row somewhere? Doesn't that > add a lot to i/o? Yes and yes, it would seem so. It could be a significant performance issue for a database with lots of updates in a short amount of time. The "current-as-of-snapshot" approach would be a valuable enhancement. Ed
On Thu, 27 Feb 2003, Andrew Sullivan wrote:
> On Thu, Feb 27, 2003 at 02:21:23PM -0700, Ed L. wrote:
> >
> > Unfortunately, dbmirror does go through all the iterations, even if
>
> So does dbmirror keep a copy of the row somewhere? Doesn't that add
> a lot to i/o?
>
> A
>
>
Ok we seam to have quite a lot of talk about replication options
here.
I need to implement one sooner or later....
Which is best seams to be on requirments and not much else. So
perhaps a list of whats currently available, its requirements and what it
is best for would be good on the web site. Here are my requirements.
1> MultiMaster (Database involves quite a lot of writes)
2> 24 x 7 operation so one server must be able to cope while the other
vacuums, backups etc,
3> Consistant all machines that are up must look the same when in master
usage.
The problem as far as I can see with sycronse systems is that they
can't cope with down time and that in my book is the primary reason for
having replication.
Peter Childs
P.S. A Hot Spare might actually be the best answer.... `
On Fri, 2003-02-28 at 04:49, Peter Childs wrote: > The problem as far as I can see with sycronse systems is that they > can't cope with down time Uh, why can't they? Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
On Friday February 28 2003 2:49, Peter Childs wrote: > > The problem as far as I can see with sycronse systems is that they > can't cope with down time and that in my book is the primary reason > for having replication. The online Postgres-R docs discuss the application of the Spread GCS to deal with traditional disadvantages with syncronous systems. Ed
On Fri, Feb 28, 2003 at 09:49:08AM +0000, Peter Childs wrote:
> 1> MultiMaster (Database involves quite a lot of writes)
There aren't any that do this right now. Define "quite a lot".
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
> > > > >Do you guys have any tentative estimates about when 7.4 is going to get released? > >What is the timeframe? Also, what is going to be there that is not in 7.3? > >I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to > wait for 7.4 and go right there... > > Hello Am I wrrong if I said that with 7.3.3 you can passed up to 32 parameters to a function and only 16 with 7.2.? Regards Luc > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Neil Conway writes: > >> I'd be quite surprised to see this in 7.4. Not that I wouldn't love to > >> have someone contribute it -- I just wouldn't bet on it being in 7.4 if > >> the beta date is around the middle of April. > > > When someone says that beta is planned April-ish, that means beta will be > > in June and the final release will be in September. Mark my words. > > If all three of these changes (Windows port, pitr, replication) get in > before feature freeze, I wouldn't want to bet that final will be any > sooner than that --- we'll have lots of testing to do. > > But we *will* freeze 7.4 features in April, and at the rate work appears > to be progressing, I wouldn't want to bet that any of these features > will be in by then ;-). If they don't make the cut, 7.4 final will > probably be a lot sooner than September. Where did you get the April date from? I didn't hear any discussion about that. I personally was thinking of June 1. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
You might want to look at my replication talk:
http://candle.pha.pa.us/main/writings/pgsql/replication.pdf
Basically, single-master uses async because it is faster, but when you
need multimaster, you usually need sync or a Postgres-R-type approach.
Seems there too may replication needs, so even Postgres-R will remain a
plugin option for PostgreSQL, like the other replication solutions.
---------------------------------------------------------------------------
Herv� Piedvache wrote:
> Le Mercredi 26 F?vrier 2003 07:52, Tom Lane a ?crit :
> > Neil Conway <neilc@samurai.com> writes:
> > > On Tue, 2003-02-25 at 22:44, Ed L. wrote:
> > >> And do I understand correctly the replication to be eventually
> > >> included will be an embedded syncronous replication solution based on
> > >> Postgres-R and the Spread GCS?
> > >
> > > No, I don't think that's set in stone (although I can't speak for the
> > > core team). While I think Postgres-R is promising, there might be room
> > > for additional replication implementations that cater to different sets
> > > of requirements.
> >
> > There absolutely *is* room for multiple replication implementations.
> > AFAICS there's no one-size-fits-all approach. I did and still do like
> > Postgres-R as a pretty useful approach, but it should not be mistaken
> > for The One True Path.
> >
> > Also, there are nontrivial licensing issues involved. The PG-R design
> > depends on an underlying "group communication" system, which is a
> > nontrivial bit of software that none of the core team wants to rewrite.
> > But none of the available GC systems are BSD-license open source. We
> > had had some hopes of getting Spread to offer BSD terms, but that seems
> > to have fallen through. So right now, PG-R is on the outside looking
> > in, as far as inclusion in the core distribution goes :-(
> >
> > regards, tom lane
>
> You mean the PG-R project will no be included in the PostgreSQL project
> unless someone rewrite the Spread GCS concept or similar system in a BSD
> licence ?
>
> What a bad news for the community ... ! :o(
>
> PG-R seems to be the best integrated solution of the moment ... Still a lot
> of work ... but Darren and others are making a real good job !
>
> DBMirror or rserv (commercial application) seems to be only triggers, and
> little demon not included in PostgreSQL system ... as PG-R is ...
>
> PostgreSQL really need an official Replication solution to be definitively
> secured in a productive environnement ... and I think I'm not the only one
> thinking like that ... looking the survey of Postgres.org web site :
> http://www.postgresql.org/survey.php?View=1&SurveyID=9
> --
> Herv? Piedvache
>
> Elma Ing?nierie Informatique
> 6 rue du Faubourg Saint-Honor?
> F-75008 - Paris - France
> Tel. 33-144949901
> fax. 33-144949902
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> But we *will* freeze 7.4 features in April, and at the rate work appears
>> to be progressing, I wouldn't want to bet that any of these features
>> will be in by then ;-). If they don't make the cut, 7.4 final will
>> probably be a lot sooner than September.
> Where did you get the April date from? I didn't hear any discussion
> about that. I personally was thinking of June 1.
We hadn't actually set a date yet, but I had been thinking end of April.
The point stands either way --- if there's any progress being made on
any of those features, it's not visible from where I sit.
regards, tom lane
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Neil Conway writes: > >> I'd be quite surprised to see this in 7.4. Not that I wouldn't love to > >> have someone contribute it -- I just wouldn't bet on it being in 7.4 if > >> the beta date is around the middle of April. > > > When someone says that beta is planned April-ish, that means beta will be > > in June and the final release will be in September. Mark my words. > > If all three of these changes (Windows port, pitr, replication) get in > before feature freeze, I wouldn't want to bet that final will be any > sooner than that --- we'll have lots of testing to do. > > But we *will* freeze 7.4 features in April, and at the rate work appears > to be progressing, I wouldn't want to bet that any of these features > will be in by then ;-). If they don't make the cut, 7.4 final will > probably be a lot sooner than September. Also, as discussed in 7.3, I vote against a feature freeze that is significantly earlier (>2 weeks) from the start of beta. We did that for 7.2, and it paralized the end of the developement period. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> But we *will* freeze 7.4 features in April, and at the rate work appears > >> to be progressing, I wouldn't want to bet that any of these features > >> will be in by then ;-). If they don't make the cut, 7.4 final will > >> probably be a lot sooner than September. > > > Where did you get the April date from? I didn't hear any discussion > > about that. I personally was thinking of June 1. > > We hadn't actually set a date yet, but I had been thinking end of April. > > The point stands either way --- if there's any progress being made on > any of those features, it's not visible from where I sit. I have the Win32 port planned for March for me. I haven't talked to Patrick about PITR (added him to CC), but maybe he would like to chime in. I haven't heard Postgres-R hooks, which is where we are now in the plan, are ready to go. So you were thinking of beta for May 1? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, as discussed in 7.3, I vote against a feature freeze that is
> significantly earlier (>2 weeks) from the start of beta. We did that
> for 7.2, and it paralized the end of the developement period.
The problem there was not the feature freeze, it was that we kept
slipping the beta date while we waited around for certain items
to get done. The lesson I take away from the past couple releases
is that you set a target beta date and then stick to it; features
that aren't in on time don't get extensions.
In other words, we shouldn't be waving our hands and saying "there's
still plenty of time for these things to happen for 7.4". There's
not, unless we go back to the previous philosophy of "we'll slip
the release as long as it takes for something to happen". I think
it's past time to light a fire under the folks who are supposedly
doing these items.
regards, tom lane
On Thu, 2003-03-06 at 11:50, Bruce Momjian wrote: > So you were thinking of beta for May 1? Rather than picking an arbitrary date for the beta, wouldn't it make more sense to simply put out the beta when a particular set of features are finished (say, Win32 + PITR + ...) The potential downside is that the development period will drag on and on, waiting for the delinquent features to be implemented. The upside is that when we actually do make the release, we'll be sure that we have enough features to justify an upgrade. As has been often remarked, upgrading PostgreSQL is somewhat painful. I'd much rather make periodic releases with major feature improvements than more frequent, incremental releases -- because the initdb/reload pain will be the same in either case. Anyway, just throwing it out there... :-) Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Also, as discussed in 7.3, I vote against a feature freeze that is > > significantly earlier (>2 weeks) from the start of beta. We did that > > for 7.2, and it paralized the end of the developement period. > > The problem there was not the feature freeze, it was that we kept > slipping the beta date while we waited around for certain items > to get done. The lesson I take away from the past couple releases > is that you set a target beta date and then stick to it; features > that aren't in on time don't get extensions. OK, let's follow that logic. Do we have enough to justify a release without any of those features? I don't think so. > In other words, we shouldn't be waving our hands and saying "there's > still plenty of time for these things to happen for 7.4". There's > not, unless we go back to the previous philosophy of "we'll slip > the release as long as it takes for something to happen". I think > it's past time to light a fire under the folks who are supposedly > doing these items. I do remember in 7.2 an attempt to come to a controlled slowdown 4-6 weeks before we even planned on starting beta. The later problem was that beta start was one month late, and then dragged, so there were multiple problems with that release: stop features late July, early August; beta scheduled September 1, started October 1; then dragged waiting for fixes rather than backing out features. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> The problem there was not the feature freeze, it was that we kept
>> slipping the beta date while we waited around for certain items
>> to get done. The lesson I take away from the past couple releases
>> is that you set a target beta date and then stick to it; features
>> that aren't in on time don't get extensions.
> OK, let's follow that logic. Do we have enough to justify a release
> without any of those features? I don't think so.
Sure we do. A quick scan of the CVS logs reminds me that we have
already done a bunch of stuff:
btree index space recycling
free-space-map management improvements
IN, NOT IN via hashtables and/or joins
hash-based aggregation
merge/hash on expressions more complex than simple Vars
deduction of equality on expressions other than simple Vars
hash joins can use more than one join key
smarter planning of outer joins
join syntax doesn't necessarily constrain plan
smarter planning of nestloop inner indexscans with multiple outer relations
new regex library
domain CHECK constraints
ALTER DOMAIN
grant options, cascaded revoke
print more information about deadlocks
information schema
read-only transactions
first-class COALESCE and NULLIF constructs (no duplicate evaluation)
IPv6 connections
Simple SQL functions expand into inline expressions
Eliminate memory leaks in SQL functions
CLUSTER ALL
transaction-safe TRUNCATE
FOR EACH STATEMENT triggers
ON COMMIT PRESERVE/DELETE ROWS for temp tables
(plus lots more minor things) --- and we still have a couple months of
development left. I don't see a good reason to delay releasing these
features if other ones aren't ready.
regards, tom lane
Yes, those are nice, but they aren't killer features like Win32 or PITR. I was hoping for one or two killer features for 7.4. Considering a feature freeze two weeks before beta, we are looking at six weeks left. I don't know that I can do Win32 in six weeks. If we go for June 1, we are looking at ten weeks. Can I get comments from others? --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> The problem there was not the feature freeze, it was that we kept > >> slipping the beta date while we waited around for certain items > >> to get done. The lesson I take away from the past couple releases > >> is that you set a target beta date and then stick to it; features > >> that aren't in on time don't get extensions. > > > OK, let's follow that logic. Do we have enough to justify a release > > without any of those features? I don't think so. > > Sure we do. A quick scan of the CVS logs reminds me that we have > already done a bunch of stuff: > > btree index space recycling > free-space-map management improvements > IN, NOT IN via hashtables and/or joins > hash-based aggregation > merge/hash on expressions more complex than simple Vars > deduction of equality on expressions other than simple Vars > hash joins can use more than one join key > smarter planning of outer joins > join syntax doesn't necessarily constrain plan > smarter planning of nestloop inner indexscans with multiple outer relations > new regex library > domain CHECK constraints > ALTER DOMAIN > grant options, cascaded revoke > print more information about deadlocks > information schema > read-only transactions > first-class COALESCE and NULLIF constructs (no duplicate evaluation) > IPv6 connections > Simple SQL functions expand into inline expressions > Eliminate memory leaks in SQL functions > CLUSTER ALL > transaction-safe TRUNCATE > FOR EACH STATEMENT triggers > ON COMMIT PRESERVE/DELETE ROWS for temp tables > > (plus lots more minor things) --- and we still have a couple months of > development left. I don't see a good reason to delay releasing these > features if other ones aren't ready. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Hi Bruce, PITR is still on my plate although I have not had much time to work on it. There was a slight shift of focus regarding PostgreSQL - Red Hat Edition (Red Hat Database) and that consumed the majority of my time over the past two months. The good news is that time has been cleared off my schedule for this work. Tom is coming up at the end of March and I hope to have a limited walkthrough at that time. Cheers, Patrick Bruce Momjian wrote: > Tom Lane wrote: > >>Bruce Momjian <pgman@candle.pha.pa.us> writes: >> >>>Tom Lane wrote: >>> >>>>But we *will* freeze 7.4 features in April, and at the rate work appears >>>>to be progressing, I wouldn't want to bet that any of these features >>>>will be in by then ;-). If they don't make the cut, 7.4 final will >>>>probably be a lot sooner than September. >>> >>>Where did you get the April date from? I didn't hear any discussion >>>about that. I personally was thinking of June 1. >> >>We hadn't actually set a date yet, but I had been thinking end of April. >> >>The point stands either way --- if there's any progress being made on >>any of those features, it's not visible from where I sit. > > > I have the Win32 port planned for March for me. I haven't talked to > Patrick about PITR (added him to CC), but maybe he would like to chime in. > I haven't heard Postgres-R hooks, which is where we are now in the plan, > are ready to go. > > So you were thinking of beta for May 1? >
On Thu, 2003-03-06 at 13:10, Bruce Momjian wrote: > > Yes, those are nice, but they aren't killer features like Win32 or PITR. > I was hoping for one or two killer features for 7.4. > > Considering a feature freeze two weeks before beta, we are looking at > six weeks left. I don't know that I can do Win32 in six weeks. If we > go for June 1, we are looking at ten weeks. > > Can I get comments from others? > I really like some of the features Tom listed, but I tend to agree with Bruce on this one; none of those features are terribly compelling. We could release without win32 or replication, but those are the "biguns", and without one of those I think 7.4 will be less than exciting. I sure part of Tom's concern is what happens when June 1st rolls around and win32/replication still isn't ready? Perhaps the official feature freeze date should be kept as May 1st, at which time we'll reevaluate where win32/replication stand and make a decision at that time. This way no one should be taken by surprise if feature freeze actually sticks on May 1st, and we'll know if we're looking at extending development by a couple of weeks for a killer app, or if the features are more than a month off we can decide to go on without them. Robert Treat
Neil Conway <neilc@samurai.com> writes:
> On Thu, 2003-03-06 at 11:50, Bruce Momjian wrote:
>> So you were thinking of beta for May 1?
> Rather than picking an arbitrary date for the beta, wouldn't it make
> more sense to simply put out the beta when a particular set of features
> are finished (say, Win32 + PITR + ...)
We did that for 7.1, and again in 7.2; and it was a bad mistake both
times, because we found ourselves in a state where "it's almost done
except X" --- and no one except the person working on X could really
do any further development.
For 7.3 we agreed to set a firm feature-freeze cutoff date well in
advance. That worked a *lot* better, and I'd like to stick with that
approach.
I don't actually much care whether the cutoff is May 1 or June 1 or
whatever. But I want it set in advance, and stuck to, so that people
can plan their own efforts without wondering what will be happening.
regards, tom lane
Yes, the big trick is to set the deadline weeks before, and if you need to delay, you do it long before the deadline arrives. Meaning, if you want to deadline May 1, you should decide that April 1, and if you decide to change your mind, you should jump another month, so decide by mid-May if June 1 is going to work. --------------------------------------------------------------------------- Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > On Thu, 2003-03-06 at 11:50, Bruce Momjian wrote: > >> So you were thinking of beta for May 1? > > > Rather than picking an arbitrary date for the beta, wouldn't it make > > more sense to simply put out the beta when a particular set of features > > are finished (say, Win32 + PITR + ...) > > We did that for 7.1, and again in 7.2; and it was a bad mistake both > times, because we found ourselves in a state where "it's almost done > except X" --- and no one except the person working on X could really > do any further development. > > For 7.3 we agreed to set a firm feature-freeze cutoff date well in > advance. That worked a *lot* better, and I'd like to stick with that > approach. > > I don't actually much care whether the cutoff is May 1 or June 1 or > whatever. But I want it set in advance, and stuck to, so that people > can plan their own efforts without wondering what will be happening. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Patrick Macdonald wrote: > Hi Bruce, > > PITR is still on my plate although I have not had much time to work on > it. There was a slight shift of focus regarding PostgreSQL - Red Hat > Edition (Red Hat Database) and that consumed the majority of my time > over the past two months. The good news is that time has been cleared > off my schedule for this work. Tom is coming up at the end of March > and I hope to have a limited walkthrough at that time. Patrick, what does "limited walkthrough" mean? Code done or coding ideas? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce, It means I'll walk through what I have at the time. The code won't be complete but the intent is to identify what's missing. Patrick Bruce Momjian wrote: > > Patrick Macdonald wrote: > > Hi Bruce, > > > > PITR is still on my plate although I have not had much time to work on > > it. There was a slight shift of focus regarding PostgreSQL - Red Hat > > Edition (Red Hat Database) and that consumed the majority of my time > > over the past two months. The good news is that time has been cleared > > off my schedule for this work. Tom is coming up at the end of March > > and I hope to have a limited walkthrough at that time. > > Patrick, what does "limited walkthrough" mean? Code done or coding > ideas? > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup. | Newtown Square, Pennsylvania 19073