Thread: 7.5 features
Here are features that are being worked on, hopefully for 7.5: o tablespaces (Gavin)o nested transactions (Alvaro)o two-phase commit (Heikki Linnakangas)o integrated pg_autovacuum(O'Connor)o PITR (Riggs)o Win32 (Claudio, Magnus) If we get the majority of them, and I think we will, this will be a great release. -- 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, Pennsylvania19073
I think great would be an understatement.
Great work all!
|---------+---------------------------------->
| | Bruce Momjian |
| | <pgman@candle.pha.pa.us|
| | > |
| | Sent by: |
| | pgsql-hackers-owner@pos|
| | tgresql.org |
| | |
| | |
| | 04/27/2004 08:27 AM |
| | |
|---------+---------------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
| | To: PostgreSQL-development <pgsql-hackers@postgresql.org>
| | cc:
| | Subject: [HACKERS] 7.5 features
|
>------------------------------------------------------------------------------------------------------------------------------|
Here are features that are being worked on, hopefully for 7.5:
o tablespaces (Gavin) o nested transactions (Alvaro) o two-phase commit (Heikki
Linnakangas) o integrated pg_autovacuum (O'Connor) o PITR (Riggs) o Win32 (Claudio,
Magnus)
If we get the majority of them, and I think we will, this will be a
great release.
-- 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
*************************************************************************
PRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is for the exclusive use of addressee and may
containproprietary, confidential and/or privileged information. If you are not the intended recipient, any use,
copying,disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient,
pleasenotify the sender immediately by return e-mail, delete this communication and destroy all copies.
*************************************************************************
On Tuesday 27 April 2004 14:27, Bruce Momjian wrote: > Here are features that are being worked on, hopefully for 7.5: > > o tablespaces (Gavin) > o nested transactions (Alvaro) > o two-phase commit (Heikki Linnakangas) > o integrated pg_autovacuum (O'Connor) > o PITR (Riggs) > o Win32 (Claudio, Magnus) > > If we get the majority of them, and I think we will, this will be a > great release. Sounds like the biggest release since 7.0 to me, and all good stuff. I do have a nagging concern with the Windows support though. I'm guessing most people running Windows servers will either be running php on top, or have windows clients. AFAIK this means .NET or ODBC, and for older Access-based systems upgrading definitely ODBC. Dave Page has bravely stepped into the breach to maintain the ODBC driver, but the niggles in it will generate a flood of support messages as Windows users test it out. Basically, I'm asking what would need to be done technically for the ODBC driver, and is there anything a non-hacker can do to help? -- Richard Huxton Archonet Ltd
El Tuesday 27 April 2004 10:27, Bruce Momjian escribió: > Here are features that are being worked on, hopefully for 7.5: > > o tablespaces (Gavin) > o nested transactions (Alvaro) > o two-phase commit (Heikki Linnakangas) > o integrated pg_autovacuum (O'Connor) > o PITR (Riggs) > o Win32 (Claudio, Magnus) > > If we get the majority of them, and I think we will, this will be a > great release. How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs (depending on how stable it gets)? -- 11:21:02 up 49 days, 15:45, 4 users, load average: 0.53, 0.68, 0.71 ----------------------------------------------------------------- Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar' Centro de Telematica | DBA, Programador, Administrador Universidad Nacional del Litoral -----------------------------------------------------------------
On Tue, 27 Apr 2004, Richard Huxton wrote: > Dave Page has bravely stepped into the breach to maintain the ODBC > driver, but the niggles in it will generate a flood of support messages > as Windows users test it out. Basically, I'm asking what would need to > be done technically for the ODBC driver, and is there anything a > non-hacker can do to help? First question ... what niggles? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Tue, 27 Apr 2004, Martin Marques wrote: > El Tuesday 27 April 2004 10:27, Bruce Momjian escribió: > > Here are features that are being worked on, hopefully for 7.5: > > > > o tablespaces (Gavin) > > o nested transactions (Alvaro) > > o two-phase commit (Heikki Linnakangas) > > o integrated pg_autovacuum (O'Connor) > > o PITR (Riggs) > > o Win32 (Claudio, Magnus) > > > > If we get the majority of them, and I think we will, this will be a > > great release. > > How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs > (depending on how stable it gets)? Zero chance ... Slony-I is *a* replication solution, not *the* replication solution ... unless someone ever comes up with an 'end all and be all' replication solution (which, personally, I don't think will ever happen), we should not be officially endorsing any one replication solution ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Tuesday 27 April 2004 15:22, Martin Marques wrote: > > How's Jans' Slowny-I doing? Any chance of getting it at least in the > contribs (depending on how stable it gets)? There was a post from Jan the other day (on General iirc) - I think he's looking for testers at the moment before he goes to feature-freeze. -- Richard Huxton Archonet Ltd
> > How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs > > (depending on how stable it gets)? > > Zero chance ... Slony-I is *a* replication solution, not *the* > replication solution ... unless someone ever comes up with an 'end all and Not to mention Jan doesn't want it to be in contrib as that would imply it was version specific. One of the more popular uses of Slony will be version upgrades with minimal downtime.
Martin Marques wrote: > El Tuesday 27 April 2004 10:27, Bruce Momjian escribi?: > > Here are features that are being worked on, hopefully for 7.5: > > > > o tablespaces (Gavin) > > o nested transactions (Alvaro) > > o two-phase commit (Heikki Linnakangas) > > o integrated pg_autovacuum (O'Connor) > > o PITR (Riggs) > > o Win32 (Claudio, Magnus) > > > > If we get the majority of them, and I think we will, this will be a > > great release. > > How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs > (depending on how stable it gets)? Yep, I forgot that, though it is independent of the 7.5 release. I think Jan will make a final release in a few months. I also should mention server-side java, again also an independent project. -- 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, Pennsylvania19073
On Tue, 2004-04-27 at 09:27, Bruce Momjian wrote: > Here are features that are being worked on, hopefully for 7.5: > > o tablespaces (Gavin) > o nested transactions (Alvaro) > o two-phase commit (Heikki Linnakangas) > o integrated pg_autovacuum (O'Connor) > o PITR (Riggs) > o Win32 (Claudio, Magnus) > > If we get the majority of them, and I think we will, this will be a > great release. Dare I even mention calling it 8.0? (ducks and runs for cover...)
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Here are features that are being worked on, hopefully for 7.5:
> o tablespaces (Gavin)
> o nested transactions (Alvaro)
> o two-phase commit (Heikki Linnakangas)
> o integrated pg_autovacuum (O'Connor)
> o PITR (Riggs)
> o Win32 (Claudio, Magnus)
Not to rain on the parade, but the *only* one of these I have any
confidence in seeing for 7.5 is the last (Windows port). The others
are still mostly or entirely handwaving, and I do not think we will
hold up the release for them once the Windows port starts looking
stable enough to beta-test.
regards, tom lane
On Tue, 27 Apr 2004, Richard Huxton wrote: > On Tuesday 27 April 2004 14:27, Bruce Momjian wrote: > > Here are features that are being worked on, hopefully for 7.5: > > > > o tablespaces (Gavin) > > o nested transactions (Alvaro) > > o two-phase commit (Heikki Linnakangas) > > o integrated pg_autovacuum (O'Connor) > > o PITR (Riggs) > > o Win32 (Claudio, Magnus) > > > > If we get the majority of them, and I think we will, this will be a > > great release. > > Sounds like the biggest release since 7.0 to me, and all good stuff. I do have > a nagging concern with the Windows support though. I'm guessing most people > running Windows servers will either be running php on top, or have windows > clients. AFAIK this means .NET or ODBC, and for older Access-based systems > upgrading definitely ODBC. > > Dave Page has bravely stepped into the breach to maintain the ODBC driver, but > the niggles in it will generate a flood of support messages as Windows users > test it out. Basically, I'm asking what would need to be done technically for > the ODBC driver, and is there anything a non-hacker can do to help? I would say the OLE-DB driver would be nice to have ready to go. There are apparently a few projects on source forge to make one that are making good progress, and it would be nice to have a fairly workable solution about the time 7.5 rolls out.
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Here are features that are being worked on, hopefully for 7.5: > > o tablespaces (Gavin) > > o nested transactions (Alvaro) > > o two-phase commit (Heikki Linnakangas) > > o integrated pg_autovacuum (O'Connor) > > o PITR (Riggs) > > o Win32 (Claudio, Magnus) > > Not to rain on the parade, but the *only* one of these I have any > confidence in seeing for 7.5 is the last (Windows port). The others > are still mostly or entirely handwaving, and I do not think we will > hold up the release for them once the Windows port starts looking > stable enough to beta-test. Gavin says he has patches for tablespaces, Alvaro has submitted patches already, server-side java is heading into beta, and Heikki has two-phase commit patches because he already worried about drift. PITR patches have been submitted too. I wouldn't call them done, but I wouldn't call them handwaving either. What we really need is for these folks to start finalizing their patches and get them submitted. -- 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, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What we really need is for these folks to start finalizing their patches
> and get them submitted.
Eggzackle ... my point is that I see the win32 train leaving the station
pretty soon, and I don't see anyone else ready to get on board.
regards, tom lane
Tom Lane said: > Bruce Momjian <pgman@candle.pha.pa.us> writes: >> What we really need is for these folks to start finalizing their >> patches and get them submitted. > > Eggzackle ... my point is that I see the win32 train leaving the > station pretty soon, and I don't see anyone else ready to get on board. > > Not quite yet - yesterday I got hold of a windows box for the first time in months and had significant building problems (the symlink problem and others). This needs to be robust. I will be sending in some fixes in due course. Is it time to set a tentative target date for a feature freeze, though? Perhaps some time in mid to late June would be good. That way people could work to a known timeline. cheers andrew
Andrew Dunstan wrote: > Tom Lane said: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> What we really need is for these folks to start finalizing their > >> patches and get them submitted. > > > > Eggzackle ... my point is that I see the win32 train leaving the > > station pretty soon, and I don't see anyone else ready to get on board. > > > > > > Not quite yet - yesterday I got hold of a windows box for the first time > in months and had significant building problems (the symlink problem and > others). This needs to be robust. I will be sending in some fixes in due > course. > > Is it time to set a tentative target date for a feature freeze, though? > Perhaps some time in mid to late June would be good. That way people could > work to a known timeline. Yes, that was the timeline I was considering too. Folks, we can be sure you have until the end of May to complete items, but after that, we don't know how soon the feature freeze will happen. -- 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, Pennsylvania19073
On Thu, 29 Apr 2004, Andrew Dunstan wrote: > Tom Lane said: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> What we really need is for these folks to start finalizing their > >> patches and get them submitted. > > > > Eggzackle ... my point is that I see the win32 train leaving the > > station pretty soon, and I don't see anyone else ready to get on board. > > > > > > Not quite yet - yesterday I got hold of a windows box for the first time > in months and had significant building problems (the symlink problem and > others). This needs to be robust. I will be sending in some fixes in due > course. > > Is it time to set a tentative target date for a feature freeze, though? > Perhaps some time in mid to late June would be good. That way people could > work to a known timeline. Right now, the feature freeze is tentative for 1st of June, which has been thrown around a few times already ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: >Right now, the feature freeze is tentative for 1st of June, which has been >thrown around a few times already ... > > > If it has I've missed it - always seemed somewhat vaguer to me. Thanks andrew
Marc G. Fournier wrote: > On Thu, 29 Apr 2004, Andrew Dunstan wrote: > > > Tom Lane said: > > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> What we really need is for these folks to start finalizing their > > >> patches and get them submitted. > > > > > > Eggzackle ... my point is that I see the win32 train leaving the > > > station pretty soon, and I don't see anyone else ready to get on board. > > > > > > > > > > Not quite yet - yesterday I got hold of a windows box for the first time > > in months and had significant building problems (the symlink problem and > > others). This needs to be robust. I will be sending in some fixes in due > > course. > > > > Is it time to set a tentative target date for a feature freeze, though? > > Perhaps some time in mid to late June would be good. That way people could > > work to a known timeline. > > Right now, the feature freeze is tentative for 1st of June, which has been > thrown around a few times already ... Yea, I think I remember that date being mentioned. -- 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, Pennsylvania19073
Andrew Dunstan wrote: > Marc G. Fournier wrote: > > >Right now, the feature freeze is tentative for 1st of June, which has been > >thrown around a few times already ... > > > > > > > > If it has I've missed it - always seemed somewhat vaguer to me. Yes, it was vague. The question is now that we are a month away, do we want to target June 1, mid-June, or July 1. Some are saying that once Win32 is ready, it will justify a release even if the other features are not ready. Looking at the list: o tablespaces (Gavin) o nested transactions (Alvaro) o two-phase commit (Heikki Linnakangas) o integrated pg_autovacuum(O'Connor) o PITR (Riggs) o Win32 (Claudio, Magnus) o replication (Sloney) o server-side Java I have talked to each person, and here is where we are on these projects: o tablespaces (Gavin) Gavin has the code 3/4 done. I told him to submit soon and he said we will have something in a few days. o nested transactions (Alvaro) Has submitted patches that are under review. He has the nesting of BEGIN done, and storage manager subtransaction handling. I think he needs to do pg_subtrans system table and error recovery. He says he can finish in time. o two-phase commit (Heikki Linnakangas) Has patches and is waiting for Alvaro's patches to be applied. Not sure how complete his patch is but it has been posted. We need to review its functionality. o integrated pg_autovacuum (O'Connor) Unknown. We need fixes for temp tables for 7.4.3 too. o PITR (Riggs) Patch submitted but now discussing how logging should be accomplished. o Win32 (Claudio, Magnus) Win32 status page lists some items still to be completed: http://momjian.postgresql.org/main/writings/pgsql/project o replication (Sloney) Released independently. Nearing beta. o server-side Java Released independently. Nearing beta or already in beta. -- 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, Pennsylvania19073
Bruce Momjian wrote: > Yes, it was vague. The question is now that we are a month away, do we > want to target June 1, mid-June, or July 1. > > Some are saying that once Win32 is ready, it will justify a release even > if the other features are not ready. I think we should have this conversation once the win32 code is ready. Since the beta period / release schedule usually takes several months in and of it self, anyone working on an item from the list below is going to lose a lot of steam if they are 80% done but get excluded from 7.5 and have to wait out the release process. > Looking at the list: > > o tablespaces (Gavin) > o nested transactions (Alvaro) > o two-phase commit (Heikki Linnakangas) > o integrated pg_autovacuum (O'Connor) > o PITR (Riggs) > o Win32 (Claudio, Magnus) > o replication (Sloney) > o server-side Java > > o integrated pg_autovacuum (O'Connor) > > Unknown. We need fixes for temp tables for 7.4.3 too. Yes I know, starting next week, I will have some time to work on this. I will fix the temp table problem first, then the 7.5 only work. FYI, I do fully intend on getting pg_autovacuum integrated for 7.5, even with a June 1 deadline. Matthew O'Connor
Matthew T. O'Connor wrote: > Bruce Momjian wrote: > > > Yes, it was vague. The question is now that we are a month away, do we > > want to target June 1, mid-June, or July 1. > > > > Some are saying that once Win32 is ready, it will justify a release even > > if the other features are not ready. > > I think we should have this conversation once the win32 code is ready. > Since the beta period / release schedule usually takes several months in > and of it self, anyone working on an item from the list below is going > to lose a lot of steam if they are 80% done but get excluded from 7.5 > and have to wait out the release process. Agreed, we will have to wait for Win32 to be completed, but Win32 also needs to try to hit that date. We can't drive the entire release process on one feature addition. What I am saying is that Win32 needs to focus on meeting that date too. The bottom line is that folks need to get their work completed or they will miss the ability to have their work in 7.5. It has happened before, and it will probably happen again in this release that some folks will not complete things in time. 7.4 was 2003-11-17 and given our usual timeline June 1 seems like a good cutoff. -- 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, Pennsylvania19073
On Thu, 29 Apr 2004, Bruce Momjian wrote: > Andrew Dunstan wrote: > > Marc G. Fournier wrote: > > > > >Right now, the feature freeze is tentative for 1st of June, which has been > > >thrown around a few times already ... > > > > > > > > > > > > > If it has I've missed it - always seemed somewhat vaguer to me. > > Yes, it was vague. The question is now that we are a month away, do we > want to target June 1, mid-June, or July 1. Target June 1st ... when May 29th or so rolls around, we can then determine whether or not we need to extend it, and why. We've gone down this road too many times, where we've extended cause a patch was "right around the corner" that finally came in a month later ... The point of a deadline is that you don't make it floating ... if the deadline arrives, and someone can justify extending it a few days to a week, then so be it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Thu, 29 Apr 2004, Bruce Momjian wrote: > > > Andrew Dunstan wrote: > > > Marc G. Fournier wrote: > > > > > > >Right now, the feature freeze is tentative for 1st of June, which has been > > > >thrown around a few times already ... > > > > > > > > > > > > > > > > > > If it has I've missed it - always seemed somewhat vaguer to me. > > > > Yes, it was vague. The question is now that we are a month away, do we > > want to target June 1, mid-June, or July 1. > > Target June 1st ... when May 29th or so rolls around, we can then > determine whether or not we need to extend it, and why. We've gone down > this road too many times, where we've extended cause a patch was "right > around the corner" that finally came in a month later ... > > The point of a deadline is that you don't make it floating ... if the > deadline arrives, and someone can justify extending it a few days to a > week, then so be it ... No. We tried that in the past and we ended up extending it in pieces several times. The effect was that we delayed feature freeze by a month or two, and other features never got developed in that timeframe. I remember SMP fixes for 7.3 as causing that problem. We didn't do that for 7.4 and it was better. -- 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, Pennsylvania19073
On Thu, Apr 29, 2004 at 01:26:07PM -0400, Bruce Momjian wrote: > o nested transactions (Alvaro) > > Has submitted patches that are under review. He has the nesting of > BEGIN done, and storage manager subtransaction handling. I think he > needs to do pg_subtrans system table and error recovery. He says he can > finish in time. > > o two-phase commit (Heikki Linnakangas) > > Has patches and is waiting for Alvaro's patches to be applied. Not sure If 2PC patches are ready and nested transactions not, is it worth considering applying 2PC when subtransactions aren't ready? I appreciate the work that will cause, so I'm not saying this lightly. It's probably too early to make that decision now, but I'd suggest keeping it in mind in case something goes off the rails. A -- Andrew Sullivan | ajs@crankycanuck.ca
Andrew Sullivan wrote: > On Thu, Apr 29, 2004 at 01:26:07PM -0400, Bruce Momjian wrote: > > o nested transactions (Alvaro) > > > > Has submitted patches that are under review. He has the nesting of > > BEGIN done, and storage manager subtransaction handling. I think he > > needs to do pg_subtrans system table and error recovery. He says he can > > finish in time. > > > > o two-phase commit (Heikki Linnakangas) > > > > Has patches and is waiting for Alvaro's patches to be applied. Not sure > > If 2PC patches are ready and nested transactions not, is it worth > considering applying 2PC when subtransactions aren't ready? I > appreciate the work that will cause, so I'm not saying this lightly. > It's probably too early to make that decision now, but I'd suggest > keeping it in mind in case something goes off the rails. 2-PC hasn't actually been posted for applicaiton, while Alvaro's have. They know they will conflict and 2PC wanted to wait for Alvaro's changes. -- 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, Pennsylvania19073
On Thu, 29 Apr 2004, Bruce Momjian wrote: > No. We tried that in the past and we ended up extending it in pieces > several times. The effect was that we delayed feature freeze by a month > or two, and other features never got developed in that timeframe. I > remember SMP fixes for 7.3 as causing that problem. We didn't do that > for 7.4 and it was better. *If* June 1st comes along, and Win32 isn't ready, there is nothing wrong with freezing the code *except* for a pending Win32 patch ... but, such a focused extension would depend on how close to being ready that pending patch is ... Again, something that cannot be accurately determined until June 1st, and by even speculating on extending, we are just makign it easier to shrug and say "not a big rush, we'll most likely extend the freeze anyway" ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> *If* June 1st comes along, and Win32 isn't ready, there is nothing wrong
> with freezing the code *except* for a pending Win32 patch ...
Yeah there is ...
In the first place it's unfair to other developers to make schedule
slips at the last moment, and especially to *plan* to do so. I would
prefer we determine at least two weeks, preferably a month, in advance
whether there is going to be a schedule change. I think it's entirely
appropriate to decide now whether we are going to hold to June 1 feature
freeze or slip it. That gives other people a chance to do useful work
while we approach the deadline.
In the second, any Win32 issues that remain unresolved as of June 1
are likely to be major enough (in terms of code impact) that we can't
realistically contemplate slipping in post-beta patches for them.
The fallback position is going to have to be no (supported) Win32 port
in 7.5, not "we'll fix this in beta".
regards, tom lane
On Thu, 29 Apr 2004, Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > *If* June 1st comes along, and Win32 isn't ready, there is nothing wrong > > with freezing the code *except* for a pending Win32 patch ... > > Yeah there is ... > > In the first place it's unfair to other developers to make schedule > slips at the last moment, and especially to *plan* to do so. Isn't it equally unfair to slip the scheduale that developers that have been working on some large features (PITR, 2PC immediately coming to mind) have been working towards based on a deadline? If Win32 that much more important then those other features? > I would prefer we determine at least two weeks, preferably a month, in > advance whether there is going to be a schedule change. I think it's > entirely appropriate to decide now whether we are going to hold to June > 1 feature freeze or slip it. That gives other people a chance to do > useful work while we approach the deadline. > > In the second, any Win32 issues that remain unresolved as of June 1 > are likely to be major enough (in terms of code impact) that we can't > realistically contemplate slipping in post-beta patches for them. > The fallback position is going to have to be no (supported) Win32 port > in 7.5, not "we'll fix this in beta". Personally, I think there are alot of large features that ppl have been hard at getting complete in time for June 1st that we should stick to it, else we're going to end up with 'yet another release' delayed in hopes that the outstanding bugs in Win32 will get fixed in a reasonable amount of time ... June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd to the Win32 Native port being finished ... If that means 8.0 happens to be September 1st, so be it ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > >Personally, I think there are alot of large features that ppl have been >hard at getting complete in time for June 1st that we should stick to it, >else we're going to end up with 'yet another release' delayed in hopes >that the outstanding bugs in Win32 will get fixed in a reasonable amount >of time ... > >June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd >to the Win32 Native port being finished ... > >If that means 8.0 happens to be September 1st, so be it ... > > > Bruce agreed that this had been vague before today, so if people have had this date in mind and have been working to it, perhaps they have some telepathic abilities I lack ... We missed on PITR *and* Win32 last year. ISTM there's a bit of a credibility issue at stake, so it might well be worth taking a couple of weeks leeway if that's what is required. The other point, especially about Win32, is to see if we can spread the load a bit. Perhaps Claudio, Magnus, Merlin and Bruce should start trying to farm out specific tasks. I for one will be very upset if it misses this release. cheers andrew
Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > *If* June 1st comes along, and Win32 isn't ready, there is nothing wrong > > with freezing the code *except* for a pending Win32 patch ... > > Yeah there is ... > > In the first place it's unfair to other developers to make schedule > slips at the last moment, and especially to *plan* to do so. I would > prefer we determine at least two weeks, preferably a month, in advance > whether there is going to be a schedule change. I think it's entirely > appropriate to decide now whether we are going to hold to June 1 feature > freeze or slip it. That gives other people a chance to do useful work > while we approach the deadline. > > In the second, any Win32 issues that remain unresolved as of June 1 > are likely to be major enough (in terms of code impact) that we can't > realistically contemplate slipping in post-beta patches for them. > The fallback position is going to have to be no (supported) Win32 port > in 7.5, not "we'll fix this in beta". Agreed. No last minute delay of the feature freeze, and no pushing major code in during beta. It sounds good now, but it makes for a big mess when it happens. We should decide now or mid-May if June 1 will be the feature freeze date. Marc is concerned that folks will not work hard to meet a deadline and will slack off if we push thing to July 1. However, looking at the open features, I haven't seen any slacking on these projects. Simon said he would submit PITR patches at the end of April, and he did. Alvaro started at the beginning of April and he is on schedule. Win32 has continued on a steady pace for six months now. What we might need to do during this time is to remind folks to submit patches for feedback regularly to keep the community involved in their progress. I think Marc's logic is that we are going to get X features into 7.5 whether we set a June 1 or July 1 feature cuttoff date. I don't think that. I would say we might get X if we choose June 1 and 1.5X if we go for July 1, based on the current state of these projects, and also based on the fact we didn't advertize the June 1 clearly enough months ago. -- 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, Pennsylvania19073
On Thu, 29 Apr 2004, Bruce Momjian wrote: > Marc is concerned that folks will not work hard to meet a deadline and > will slack off if we push thing to July 1. I don't think I'm so muc worried about that as under-estimating the amount of time required to finish them ... its not like *that's* never happened before, and with something as big as some of the features that are in the works, and with some of the major show-stoppers that the Win32 port has brought up, I can seriously see '1 month' being drawn out further ... > Win32 has continued on a steady pace for six months now. Be honest ... 6 months ago, did you believe the Win32 work would have taken >6 months? How many of the current issues could you have anticipated? How many will crop up in the next month? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Thu, 29 Apr 2004, Bruce Momjian wrote: > > > Marc is concerned that folks will not work hard to meet a deadline and > > will slack off if we push thing to July 1. > > I don't think I'm so muc worried about that as under-estimating the amount > of time required to finish them ... its not like *that's* never happened > before, and with something as big as some of the features that are in the > works, and with some of the major show-stoppers that the Win32 port has > brought up, I can seriously see '1 month' being drawn out further ... > > > Win32 has continued on a steady pace for six months now. > > Be honest ... 6 months ago, did you believe the Win32 work would have > taken >6 months? How many of the current issues could you have > anticipated? How many will crop up in the next month? Honestly, I didn't think we would be this far by now (we had regression tests mostly passing 4-6 weeks ago), and the win32 status page hasn't added a new TODO item in quite some time. I thought we would be hacking Win32 all through 7.5 beta and releasing something after 7.5 as a 7.5 plus patches release but we are far enough along to hit 7.5 by feature freeze. -- 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, Pennsylvania19073
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Thu, 29 Apr 2004, Tom Lane wrote:
>> In the first place it's unfair to other developers to make schedule
>> slips at the last moment, and especially to *plan* to do so.
> Isn't it equally unfair to slip the scheduale that developers that have
> been working on some large features (PITR, 2PC immediately coming to mind)
> have been working towards based on a deadline? If Win32 that much more
> important then those other features?
As you well know, I have no use for the Win32 port at all ;-). However,
of the "major features" that Bruce just listed, the Win32 port is the
only one I consider really likely to appear in 7.5; sure it needs major
work yet, but the others are still in the vaporware-till-proven-otherwise
category. Certainly they are not solid enough to justify making
schedule decisions on the basis of "this will probably be ready by date X".
I am willing to adjust the freeze deadline now to make it more probable
that at least one of those major features will really make it into 7.5.
The realities are that the Win32 port should determine any such schedule
decision, because nothing else is close enough to the finish line to
justify considering its needs instead.
I guess my point is really "do you want to freeze on June 1 if *none*
of these features are done?"
regards, tom lane
Tom Lane wrote: > "Marc G. Fournier" <scrappy@postgresql.org> writes: > > On Thu, 29 Apr 2004, Tom Lane wrote: > >> In the first place it's unfair to other developers to make schedule > >> slips at the last moment, and especially to *plan* to do so. > > > Isn't it equally unfair to slip the scheduale that developers that have > > been working on some large features (PITR, 2PC immediately coming to mind) > > have been working towards based on a deadline? If Win32 that much more > > important then those other features? > > As you well know, I have no use for the Win32 port at all ;-). However, > of the "major features" that Bruce just listed, the Win32 port is the > only one I consider really likely to appear in 7.5; sure it needs major > work yet, but the others are still in the vaporware-till-proven-otherwise > category. Certainly they are not solid enough to justify making > schedule decisions on the basis of "this will probably be ready by date X". > > I am willing to adjust the freeze deadline now to make it more probable > that at least one of those major features will really make it into 7.5. > The realities are that the Win32 port should determine any such schedule > decision, because nothing else is close enough to the finish line to > justify considering its needs instead. > > I guess my point is really "do you want to freeze on June 1 if *none* > of these features are done?" Yep, my point too, that we need X big features to schedule beta, and we don't have any yet. I believe PITR actually does work as Simon has tested it, and we have the code. Of course, i am discussing how it should be integrated, but I do believe it works. And I think Gavin will complete his tablespaces, perhaps with our help. -- 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, Pennsylvania19073
On Thu, 29 Apr 2004, Tom Lane wrote: > I guess my point is really "do you want to freeze on June 1 if *none* of > these features are done?" No, I agree that that would be foolish ... but there has also been alot done on the code over the past few months that even *one* of those features should be enough to put it over the top ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Thu, 29 Apr 2004, Tom Lane wrote: > > > I guess my point is really "do you want to freeze on June 1 if *none* of > > these features are done?" > > No, I agree that that would be foolish ... but there has also been alot > done on the code over the past few months that even *one* of those > features should be enough to put it over the top ... But we should have at least one done before setting a freeze date, and the freeze date should be one month in the future. Right now we have none. -- 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, Pennsylvania19073
On Fri, 30 Apr 2004, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Thu, 29 Apr 2004, Tom Lane wrote: > > > > > I guess my point is really "do you want to freeze on June 1 if *none* of > > > these features are done?" > > > > No, I agree that that would be foolish ... but there has also been alot > > done on the code over the past few months that even *one* of those > > features should be enough to put it over the top ... > > But we should have at least one done before setting a freeze date, and > the freeze date should be one month in the future. Right now we have > none. Now, that logic *doesn't* follow ... freeze date == that one feature makes more sense ... or freeze date == one month from May 1st *or* one feature, whichever is longer makes sense ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Fri, 30 Apr 2004, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > On Thu, 29 Apr 2004, Tom Lane wrote: > > > > > > > I guess my point is really "do you want to freeze on June 1 if *none* of > > > > these features are done?" > > > > > > No, I agree that that would be foolish ... but there has also been alot > > > done on the code over the past few months that even *one* of those > > > features should be enough to put it over the top ... > > > > But we should have at least one done before setting a freeze date, and > > the freeze date should be one month in the future. Right now we have > > none. > > Now, that logic *doesn't* follow ... freeze date == that one feature makes > more sense ... or freeze date == one month from May 1st *or* one feature, > whichever is longer makes sense ... But we don't want to have all our developers controlled by one feature being completed. It isn't fair. They should get a good warning about freeze starting. -- 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, Pennsylvania19073
On Fri, 30 Apr 2004, Bruce Momjian wrote: > But we don't want to have all our developers controlled by one feature > being completed. It isn't fair. They should get a good warning about > freeze starting. Nor is it fair to extend the development cycle indefinitely waiting for that one feature in the first place ... there is *nothing* that states that the 7.6 dev cycle is nice and short for a change ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Fri, 30 Apr 2004, Bruce Momjian wrote: > > > But we don't want to have all our developers controlled by one feature > > being completed. It isn't fair. They should get a good warning about > > freeze starting. > > Nor is it fair to extend the development cycle indefinitely waiting for > that one feature in the first place ... there is *nothing* that states > that the 7.6 dev cycle is nice and short for a change ... Agreed. I say we wait for _a_ major feature completed, or X major 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, Pennsylvania19073
""Andrew Dunstan"" <andrew@dunslane.net> wrote in message news:3660.24.211.141.25.1083248588.squirrel@www.dunslane.net...> Not quite yet - yesterday I got hold of a windows box forthe first time > in months and had significant building problems (the symlink problem and > others). This needs to be robust. I will be sending in some fixes in due > course. A patch fixing those problems have already been submitted by Claudio Natoli. Perhaps you already knew that. Kind regards, Thomas Hallgren
Thomas Hallgren said: > ""Andrew Dunstan"" <andrew@dunslane.net> wrote in message > news:3660.24.211.141.25.1083248588.squirrel@www.dunslane.net... > > Not quite yet - yesterday I got hold of a windows box for the first > > time >> in months and had significant building problems (the symlink problem >> and others). This needs to be robust. I will be sending in some fixes >> in due course. > A patch fixing those problems have already been submitted by Claudio > Natoli. Perhaps you already knew that. > There's yet to be agreement on how to fix this. See the hack that I used yesterday on the -win32 list. cheers andrew
On Thu, Apr 29, 2004 at 09:30:12PM -0300, Marc G. Fournier wrote: > > June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd > to the Win32 Native port being finished ... I seem to remember the same argument at 7.4 time. I don't use Windows, I think it's a bletcherous system, but I really think delaying the Windows port Yet Again will make the project almost completely irrelevant to a significant audience. I completely agree that it'd be a bad idea to slip indefinitely on the basis of "Windows is still not ready," but if it's a matter of changing freeze date by a month, given the long notice, why is that a bad thing? The Windows port is _extremely_ important for a lot of people, and I think it'd be short sighted to ignore that constituency, even if they are mostly not here yet. A -- Andrew Sullivan | ajs@crankycanuck.ca
Andrew Dunstan wrote:
>
>
> Marc G. Fournier wrote:
>
>>
>> Personally, I think there are alot of large features that ppl have been
>> hard at getting complete in time for June 1st that we should stick to it,
>> else we're going to end up with 'yet another release' delayed in hopes
>> that the outstanding bugs in Win32 will get fixed in a reasonable amount
>> of time ...
>>
>> June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd
>> to the Win32 Native port being finished ...
>>
>> If that means 8.0 happens to be September 1st, so be it ...
>>
>>
>>
>
> Bruce agreed that this had been vague before today, so if people have
> had this date in mind and have been working to it, perhaps they have
> some telepathic abilities I lack ...
>
> We missed on PITR *and* Win32 last year. ISTM there's a bit of a
> credibility issue at stake, so it might well be worth taking a couple of
> weeks leeway if that's what is required.
>
> The other point, especially about Win32, is to see if we can spread the
> load a bit. Perhaps Claudio, Magnus, Merlin and Bruce should start
> trying to farm out specific tasks. I for one will be very upset if it
> misses this release.
>
> cheers
>
> andrew
This is exactly the point ...
If you go to a conference you will ALWAYS face the same questions:
- when can we have sync. replication and failover- when can we have PITR- when can we have win32
People won't believe us anymore if you keep telling them "in the next
release".
If a feature freeze is made on August 1st or even later it would be ok
because nobody is doing major database changes in summer anyway.
Currently I cannot see a major reason why people should upgrade to 7.5
(ARC and so forth are great but they are no killer features). Maybe in
this case it is worth waiting for 2 major features to make it into the
release (let's say PITR + nested transactions or win32 and pitr or 2pc
and nested transactions). This would point out that significant progress
is made.
Regards,
Hans
--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/2952/30706 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What we really need is for these folks to start finalizing their patches
> and get them submitted.
Eggzackle ... my point is that I see the win32 train leaving the station
pretty soon, and I don't see anyone else ready to get on board.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
On Sat, May 01, 2004 at 09:03:03AM +0200, Hans-Jürgen Schönig wrote: > If a feature freeze is made on August 1st or even later it would be ok > because nobody is doing major database changes in summer anyway. You seem to forget that half of the world is not in summer on August 1st. I admit that 90% of the developers are not on _this_ half of the world though ;-) My point is that not necessarily development will stop at that time. Moreover, if there is nobody to test the beta, what good does to have a feature freeze? -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Just treat us the way you want to be treated + some extra allowance for ignorance." (Michael Brusser)
On Wed, 12 May 2004, Jan Wieck wrote: > Can we please make "move all replication software out of the release" an > official open item for the 7.5 release? Agreed ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Bruce Momjian wrote: > Tom Lane wrote: >> "Marc G. Fournier" <scrappy@postgresql.org> writes: >> > On Thu, 29 Apr 2004, Tom Lane wrote: >> >> In the first place it's unfair to other developers to make schedule >> >> slips at the last moment, and especially to *plan* to do so. >> >> > Isn't it equally unfair to slip the scheduale that developers that have >> > been working on some large features (PITR, 2PC immediately coming to mind) >> > have been working towards based on a deadline? If Win32 that much more >> > important then those other features? >> >> As you well know, I have no use for the Win32 port at all ;-). However, >> of the "major features" that Bruce just listed, the Win32 port is the >> only one I consider really likely to appear in 7.5; sure it needs major >> work yet, but the others are still in the vaporware-till-proven-otherwise >> category. Certainly they are not solid enough to justify making >> schedule decisions on the basis of "this will probably be ready by date X". >> >> I am willing to adjust the freeze deadline now to make it more probable >> that at least one of those major features will really make it into 7.5. >> The realities are that the Win32 port should determine any such schedule >> decision, because nothing else is close enough to the finish line to >> justify considering its needs instead. >> >> I guess my point is really "do you want to freeze on June 1 if *none* >> of these features are done?" > > Yep, my point too, that we need X big features to schedule beta, and we > don't have any yet. > > I believe PITR actually does work as Simon has tested it, and we have > the code. Of course, i am discussing how it should be integrated, but I > do believe it works. And I think Gavin will complete his tablespaces, > perhaps with our help. > We have ARC, the background writer and vacuum delay, and people even ask me for backports of that (I have one for vacuum delay, but refuse to make one for the others). How long do you want to delay that being ready for production? Do you really think people that are suffering from the fact that checkpoints, vacuum runs and pg_dumps bog down their machines to the state where simple queries take several seconds care that much for any Win32 port? Do you think it is a good sign for those who have been our traditional Unix user base that we delay the important enhancements that they need because we want to attract a lot of non-professional users in Windows land? I think that is the wrong signal to send. However important for marketing the Win32 port is, there are other things in the pipeline that are important for those users we have won already long time ago. Let's rather not lose them. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > We have ARC, the background writer and vacuum delay, and people even ask > me for backports of that (I have one for vacuum delay, but refuse to > make one for the others). How long do you want to delay that being ready > for production? Do you really think people that are suffering from the > fact that checkpoints, vacuum runs and pg_dumps bog down their machines > to the state where simple queries take several seconds care that much > for any Win32 port? Do you think it is a good sign for those who have > been our traditional Unix user base that we delay the important > enhancements that they need because we want to attract a lot of > non-professional users in Windows land? I think that is the wrong signal > to send. However important for marketing the Win32 port is, there are > other things in the pipeline that are important for those users we have > won already long time ago. Let's rather not lose them. Sure those are nifty enhancements, but they are not really new features. I would rather call them performance enhancements. Sure, there are some folks who can't use PostgreSQL without them, but they are not like PITR or nested transactions where you really can't easily work around the limitation. Sure, you can work around the lack of a Win32 port with Cygwin, and maybe use replication in place of PITR, but the big question is are you hitting a large precentage of users with an enhancement. I am sure i can get some "me too's" for your improvements, but it doesn't represeent dramatic new functionality for PostgreSQL. I personally don't think Win32 is enough of a new feature either, but others disagree. -- 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, Pennsylvania19073
Bruce Momjian kirjutas P, 16.05.2004 kell 22:45: > Jan Wieck wrote: > > We have ARC, the background writer and vacuum delay, and people even ask > > me for backports of that (I have one for vacuum delay, but refuse to > > make one for the others). How long do you want to delay that being ready > > for production? Do you really think people that are suffering from the > > fact that checkpoints, vacuum runs and pg_dumps bog down their machines > > to the state where simple queries take several seconds care that much > > for any Win32 port? Do you think it is a good sign for those who have > > been our traditional Unix user base that we delay the important > > enhancements that they need because we want to attract a lot of > > non-professional users in Windows land? I think that is the wrong signal > > to send. However important for marketing the Win32 port is, there are > > other things in the pipeline that are important for those users we have > > won already long time ago. Let's rather not lose them. > > Sure those are nifty enhancements, but they are not really new features. > I would rather call them performance enhancements. But it seems that they _are_ new enough features not to be included in point releases (like 7.4.3). > Sure, there are some > folks who can't use PostgreSQL without them, but they are not like PITR > or nested transactions where you really can't easily work around the > limitation. If you need a 24h non-stop database for global business, it is not acceptable to have 30-minute periods of very slow queries resulting in dropped connections. The only way to work around it without Jan's patches is not to run vacuum at all, but this is a lousy longer-term solution. > Sure, you can work around the lack of a Win32 port with Cygwin, and > maybe use replication in place of PITR, but the big question is are you > hitting a large precentage of users with an enhancement. I'm not sure that the initial version of PITR will be a good replacement for replication. > I am sure i > can get some "me too's" for your improvements, but it doesn't represeent > dramatic new functionality for PostgreSQL. For me the vacuum delay *does* represent a "dramatic new functionality" and I was quite disappointed that the simple version did not make it into 7.4. > I personally don't think Win32 is enough of a new feature either, but > others disagree. ----------- Hannu
Hannu Krosing wrote: > > Sure, you can work around the lack of a Win32 port with Cygwin, and > > maybe use replication in place of PITR, but the big question is are you > > hitting a large precentage of users with an enhancement. > > I'm not sure that the initial version of PITR will be a good replacement > for replication. > > > I am sure i > > can get some "me too's" for your improvements, but it doesn't represeent > > dramatic new functionality for PostgreSQL. > > For me the vacuum delay *does* represent a "dramatic new functionality" > and I was quite disappointed that the simple version did not make it into 7.4. Agreed, but you are a "me too", not a huge percentage of our userbase. Basically, after 6-7 months of development, I want more than a vacuum patch and a new cache replacement policy. I want something big, in fact, several big things. -- 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, Pennsylvania19073
On Sun, 16 May 2004, Bruce Momjian wrote: > I personally don't think Win32 is enough of a new feature either, but > others disagree. Jan, correct me if I'm wrong ... Jan's point is that we have enough already to warrant a beta on June 1st, even without Win32 ... Win32 (or any of the other stuff, like PITR/tablespaces) would be icing on the cake ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> Jan, correct me if I'm wrong ... Jan's point is that we have enough > already to warrant a beta on June 1st, even without Win32 ... Win32 (or > any of the other stuff, like PITR/tablespaces) would be icing on the cake > ... I think we're close enough on win32 to wait for it. It would look bad for us to miss inclusion of win32 two releases in a row... Chris
On Sun, 2004-05-16 at 23:02, Marc G. Fournier wrote: > On Sun, 16 May 2004, Bruce Momjian wrote: > > > I personally don't think Win32 is enough of a new feature either, but > > others disagree. > > Jan, correct me if I'm wrong ... Jan's point is that we have enough > already to warrant a beta on June 1st, even without Win32 ... Win32 (or > any of the other stuff, like PITR/tablespaces) would be icing on the cake I have no use for Win32 support but it would hurt to have that particular feature pushed back again.
Marc G. Fournier wrote: > On Sun, 16 May 2004, Bruce Momjian wrote: > > > I personally don't think Win32 is enough of a new feature either, but > > others disagree. > > Jan, correct me if I'm wrong ... Jan's point is that we have enough > already to warrant a beta on June 1st, even without Win32 ... Win32 (or > any of the other stuff, like PITR/tablespaces) would be icing on the cake > ... I disagree we have enough new features for a release, even with Win32. Our features are getting more complex and require more time to develop. -- 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, Pennsylvania19073
On Sun, 16 May 2004, Bruce Momjian wrote: > Hannu Krosing wrote: > > > Sure, you can work around the lack of a Win32 port with Cygwin, and > > > maybe use replication in place of PITR, but the big question is are you > > > hitting a large precentage of users with an enhancement. > > > > I'm not sure that the initial version of PITR will be a good replacement > > for replication. > > > > > I am sure i > > > can get some "me too's" for your improvements, but it doesn't represeent > > > dramatic new functionality for PostgreSQL. > > > > For me the vacuum delay *does* represent a "dramatic new functionality" > > and I was quite disappointed that the simple version did not make it into 7.4. > > Agreed, but you are a "me too", not a huge percentage of our userbase. How do you know? Have you polled our complete userbase? > Basically, after 6-7 months of development, I want more than a vacuum > patch and a new cache replacement policy. I want something big, in > fact, several big things. Most likely won't happen, since what is considered big by you isn't necessarily what is considered big by someone else ... as Hannu, and I believe, Jan, have so far pointed out to you ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 17 May 2004, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Sun, 16 May 2004, Bruce Momjian wrote: > > > > > I personally don't think Win32 is enough of a new feature either, but > > > others disagree. > > > > Jan, correct me if I'm wrong ... Jan's point is that we have enough > > already to warrant a beta on June 1st, even without Win32 ... Win32 (or > > any of the other stuff, like PITR/tablespaces) would be icing on the cake > > ... > > I disagree we have enough new features for a release, even with Win32. > Our features are getting more complex and require more time to develop. Not true ... you just have to fix your definition of what a feature is ... a feature is an improvement to the system, whether it be new functionality, or improved performance ... I consider the work Tom did on the IN performance in 7.4 to have been a major feature, considering that it made use of it *alot* more effective ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > > Agreed, but you are a "me too", not a huge percentage of our userbase. > > How do you know? Have you polled our complete userbase? > > > Basically, after 6-7 months of development, I want more than a vacuum > > patch and a new cache replacement policy. I want something big, in > > fact, several big things. > > Most likely won't happen, since what is considered big by you isn't > necessarily what is considered big by someone else ... as Hannu, and I > believe, Jan, have so far pointed out to you ... I can't poll for everything. I make my own educated guesses. For a small percentage, vacuum delay and ARC are significant. For a larger percentage, PITR, Win32, tablespaces, and nested transactions are significant. I don't need to take a poll for that, and a "me too" doesn't change that fact. To say otherwise is to pretend that all our enhancements are of equal significance. Sure, for a given individual some are very important, but in the aggregate things are pretty easy to guess. -- 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, Pennsylvania19073
Marc G. Fournier wrote: > On Mon, 17 May 2004, Bruce Momjian wrote: > > > Marc G. Fournier wrote: > > > On Sun, 16 May 2004, Bruce Momjian wrote: > > > > > > > I personally don't think Win32 is enough of a new feature either, but > > > > others disagree. > > > > > > Jan, correct me if I'm wrong ... Jan's point is that we have enough > > > already to warrant a beta on June 1st, even without Win32 ... Win32 (or > > > any of the other stuff, like PITR/tablespaces) would be icing on the cake > > > ... > > > > I disagree we have enough new features for a release, even with Win32. > > Our features are getting more complex and require more time to develop. > > Not true ... you just have to fix your definition of what a feature is ... > a feature is an improvement to the system, whether it be new > functionality, or improved performance ... I consider the work Tom did on > the IN performance in 7.4 to have been a major feature, considering that > it made use of it *alot* more effective ... See my recent email. You are stating that all features are of equal significance. Basically, the important missing features are also the ones the require the most work to complete. -- 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, Pennsylvania19073
On Mon, May 17, 2004 at 01:53:19 -0300, "Marc G. Fournier" <scrappy@postgresql.org> wrote: > > Not true ... you just have to fix your definition of what a feature is ... > a feature is an improvement to the system, whether it be new > functionality, or improved performance ... I consider the work Tom did on > the IN performance in 7.4 to have been a major feature, considering that > it made use of it *alot* more effective ... Personally, I found the 7.4 prebeta had a number of minor features that I wanted. So far I haven't seen many things of particular interest to me in 7.5. I haven't played with it yet, since there has been what appears to be some pretty significant changes in some fundemental parts of 7.5 and as such there appears to be more risk than there was at this point in 7.4s release cycle. Based on what I read about several of the "big" projects, it seems like the difference between a June 1 beta and a July 1 beta is worth taking the extra month to have a better chance at getting some of these projects in.
On Mon, 17 May 2004, Bruce Momjian wrote: > Marc G. Fournier wrote: > > > Agreed, but you are a "me too", not a huge percentage of our userbase. > > > > How do you know? Have you polled our complete userbase? > > > > > Basically, after 6-7 months of development, I want more than a vacuum > > > patch and a new cache replacement policy. I want something big, in > > > fact, several big things. > > > > Most likely won't happen, since what is considered big by you isn't > > necessarily what is considered big by someone else ... as Hannu, and I > > believe, Jan, have so far pointed out to you ... > > I can't poll for everything. I make my own educated guesses. Based on what though? All the clients that I deal with on a daily basis generally care about is performance ... that is generally what they upgrade for ... so, my 'educated guess' based on real world users is that Win32, PITR and nested transactions are not important ... tablespaces, I have one client that has asked about something *similar* to it, but tablespaces, for him, doesn't come close to what they would like to see ... So, my 'educated guess' is different then yours is ... does that make yours wrong? Nope ... just means we have different sample sets to work with ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 17 May 2004, Bruce Momjian wrote: > See my recent email. You are stating that all features are of equal > significance. Basically, the important missing features are also the > ones the require the most work to complete. Agreed ... and the ones that require the most work to complete *will* span multiple releases in between if they have to ... just because something doesn't make it into 7.5 doesn't mean that the developer is going to drop all their work and start from scratch hoping to make it into 7.6 ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 17 May 2004, Bruno Wolff III wrote: > On Mon, May 17, 2004 at 01:53:19 -0300, > "Marc G. Fournier" <scrappy@postgresql.org> wrote: > > > > Not true ... you just have to fix your definition of what a feature is ... > > a feature is an improvement to the system, whether it be new > > functionality, or improved performance ... I consider the work Tom did on > > the IN performance in 7.4 to have been a major feature, considering that > > it made use of it *alot* more effective ... > > Personally, I found the 7.4 prebeta had a number of minor features that I > wanted. So far I haven't seen many things of particular interest to me > in 7.5. I haven't played with it yet, since there has been what appears > to be some pretty significant changes in some fundemental parts of 7.5 > and as such there appears to be more risk than there was at this point in > 7.4s release cycle. > > Based on what I read about several of the "big" projects, it seems like > the difference between a June 1 beta and a July 1 beta is worth taking > the extra month to have a better chance at getting some of these projects in. Key words: "better chance" ... it doesn't mean that *any* of them will get done even in that extra month, you are speculating that that one month will make a difference. Then, when that month is up, and nothing does materialize (devil's advocate here), do we add another month to 'have a better chance'? Where does it end? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
> On Mon, 17 May 2004, Bruce Momjian wrote:
>
>
>>Marc G. Fournier wrote:
>>
>>>>Agreed, but you are a "me too", not a huge percentage of our userbase.
>>>
>>>How do you know? Have you polled our complete userbase?
>>>
>>>
>>>>Basically, after 6-7 months of development, I want more than a vacuum
>>>>patch and a new cache replacement policy. I want something big, in
>>>>fact, several big things.
>>>
>>>Most likely won't happen, since what is considered big by you isn't
>>>necessarily what is considered big by someone else ... as Hannu, and I
>>>believe, Jan, have so far pointed out to you ...
>>
>>I can't poll for everything. I make my own educated guesses.
>
>
> Based on what though?
>
> All the clients that I deal with on a daily basis generally care about is
> performance ... that is generally what they upgrade for ... so, my
> 'educated guess' based on real world users is that Win32, PITR and nested
> transactions are not important ... tablespaces, I have one client that has
> asked about something *similar* to it, but tablespaces, for him, doesn't
> come close to what they would like to see ...
>
> So, my 'educated guess' is different then yours is ... does that make
> yours wrong? Nope ... just means we have different sample sets to work
> with ...
>
Interesting.
We have made COMPLETELY different experiences.
There is one question people ask me daily: "When can we have sychronous
replication and PITR?".
Performance is not a problem here. People are more interested in
stability and "enterprise" features such as those I have mentioned above.
I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...
Most likely this is not very encourageing for the developers involved ...
Regards,
Hans
--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
Hans-J�rgen Sch�nig wrote: > > All the clients that I deal with on a daily basis generally care about is > > performance ... that is generally what they upgrade for ... so, my > > 'educated guess' based on real world users is that Win32, PITR and nested > > transactions are not important ... tablespaces, I have one client that has > > asked about something *similar* to it, but tablespaces, for him, doesn't > > come close to what they would like to see ... > > > > So, my 'educated guess' is different then yours is ... does that make > > yours wrong? Nope ... just means we have different sample sets to work > > with ... > > > > > Interesting. > We have made COMPLETELY different experiences. > > There is one question people ask me daily: "When can we have sychronous > replication and PITR?". > Performance is not a problem here. People are more interested in > stability and "enterprise" features such as those I have mentioned above. > > I am still wondering about two things: > Somebody has posted a 2PC patch - I haven't seen too many comments He is waiting for nested transactions to be committed so he can merge his work in. > Somebody has posted sync multimaster replication (PgCluster) - nobody > has commented on that. Maybe I am the only one who has ever tried it ... I think it should be on gborg. -- 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, Pennsylvania19073
Marc G. Fournier wrote: > On Sun, 16 May 2004, Bruce Momjian wrote: > >> I personally don't think Win32 is enough of a new feature either, but >> others disagree. > > Jan, correct me if I'm wrong ... Jan's point is that we have enough > already to warrant a beta on June 1st, even without Win32 ... Win32 (or > any of the other stuff, like PITR/tablespaces) would be icing on the cake > ... I agree that we don't have many of the "big marketing bang for the buck" features done for 7.5. But that is no reason to use wordings like "nifty enhancements" or "for a small percentage" in an attempt to make what we have look uninteresting for the average user so that it looks wise to wait, and wait, and wait. Just that someone doesn't understand the importance of these issues because he doesn't deal with the type of customer that values a good standard deviation on response times doesn't make Win32 more important. Judging by those standards, we probably shouldn't have had 7.4 at all, and we probably shouldn't claim that we want to attract typical Oracle users either. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Christopher Kings-Lynne wrote: >> Jan, correct me if I'm wrong ... Jan's point is that we have enough >> already to warrant a beta on June 1st, even without Win32 ... Win32 (or >> any of the other stuff, like PITR/tablespaces) would be icing on the cake >> ... > > I think we're close enough on win32 to wait for it. It would look bad > for us to miss inclusion of win32 two releases in a row... Yes, unless this is "forever". Is there a clear commitment that Win32 will be done if we push from June to July? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > Christopher Kings-Lynne wrote: > > >> Jan, correct me if I'm wrong ... Jan's point is that we have enough > >> already to warrant a beta on June 1st, even without Win32 ... Win32 (or > >> any of the other stuff, like PITR/tablespaces) would be icing on the cake > >> ... > > > > I think we're close enough on win32 to wait for it. It would look bad > > for us to miss inclusion of win32 two releases in a row... > > Yes, unless this is "forever". Is there a clear commitment that Win32 > will be done if we push from June to July? It is too late to think about pushing back another month. We had this discussion already. June 1 is it. I do think Win32 will make it, though. -- 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, Pennsylvania19073
On Monday 17 May 2004 08:21, Bruce Momjian wrote:
> Hans-Jürgen Schönig wrote:
> > I am still wondering about two things:
> > Somebody has posted a 2PC patch - I haven't seen too many comments
>
> He is waiting for nested transactions to be committed so he can merge
> his work in.
>
I was thinking about this over the weekend... if nested transactions doesn't
make it into 7.5, does this mean that we won't get 2PC either? Seems that
would be a shame if we have a 2PC patch that is ready to go...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > On Monday 17 May 2004 08:21, Bruce Momjian wrote: > > Hans-J?rgen Sch?nig wrote: > > > I am still wondering about two things: > > > Somebody has posted a 2PC patch - I haven't seen too many comments > > > > He is waiting for nested transactions to be committed so he can merge > > his work in. > > > > I was thinking about this over the weekend... if nested transactions doesn't > make it into 7.5, does this mean that we won't get 2PC either? Seems that > would be a shame if we have a 2PC patch that is ready to go... No idea. The 2PC author wanted to wait for subtransactions. It wasn't our idea. -- 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, Pennsylvania19073
Hans-Jürgen Schönig wrote: > Marc G. Fournier wrote: >> On Mon, 17 May 2004, Bruce Momjian wrote: >> >> >>>Marc G. Fournier wrote: >>> >>>>>Agreed, but you are a "me too", not a huge percentage of our userbase. >>>> >>>>How do you know? Have you polled our complete userbase? >>>> >>>> >>>>>Basically, after 6-7 months of development, I want more than a vacuum >>>>>patch and a new cache replacement policy. I want something big, in >>>>>fact, several big things. >>>> >>>>Most likely won't happen, since what is considered big by you isn't >>>>necessarily what is considered big by someone else ... as Hannu, and I >>>>believe, Jan, have so far pointed out to you ... >>> >>>I can't poll for everything. I make my own educated guesses. >> >> >> Based on what though? >> >> All the clients that I deal with on a daily basis generally care about is >> performance ... that is generally what they upgrade for ... so, my >> 'educated guess' based on real world users is that Win32, PITR and nested >> transactions are not important ... tablespaces, I have one client that has >> asked about something *similar* to it, but tablespaces, for him, doesn't >> come close to what they would like to see ... >> >> So, my 'educated guess' is different then yours is ... does that make >> yours wrong? Nope ... just means we have different sample sets to work >> with ... >> > > > Interesting. > We have made COMPLETELY different experiences. > > There is one question people ask me daily: "When can we have sychronous > replication and PITR?". > Performance is not a problem here. People are more interested in > stability and "enterprise" features such as those I have mentioned above. > > I am still wondering about two things: > Somebody has posted a 2PC patch - I haven't seen too many comments > Somebody has posted sync multimaster replication (PgCluster) - nobody > has commented on that. Maybe I am the only one who has ever tried it ... Do you really need someone "commenting" on query based replication? I get goosebumps from just thinking someone would voluntarily push all sequence- or timestamp-generation and other not strictly deterministic functionality into the application to be able to use such a "solution". This is exactly how people work around all the MySQL idiosyncrasies. > > Most likely this is not very encourageing for the developers involved ... Most hopefully this is very discouraging! Connection pools are a nice thing and I have used pgpool recently with great success, for pooling connections. But attempting to deliver multimaster replication as a byproduct of a connection pool isn't going to become an enterprise feature. And the more half-baked, half-functional and half-reliable replication attempts there are, the harder it will be to finally get a real solution being recognized. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck wrote: > > I am still wondering about two things: > > Somebody has posted a 2PC patch - I haven't seen too many comments > > Somebody has posted sync multimaster replication (PgCluster) - nobody > > has commented on that. Maybe I am the only one who has ever tried it ... > > Do you really need someone "commenting" on query based replication? I > get goosebumps from just thinking someone would voluntarily push all > sequence- or timestamp-generation and other not strictly deterministic > functionality into the application to be able to use such a "solution". > This is exactly how people work around all the MySQL idiosyncrasies. > > > > > Most likely this is not very encourageing for the developers involved ... > > Most hopefully this is very discouraging! Connection pools are a nice > thing and I have used pgpool recently with great success, for pooling > connections. But attempting to deliver multimaster replication as a > byproduct of a connection pool isn't going to become an enterprise > feature. And the more half-baked, half-functional and half-reliable > replication attempts there are, the harder it will be to finally get a > real solution being recognized. Well, considering we offer _nothing_ for multi-master right now, I think it is a valuable project. -- 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, Pennsylvania19073
Jan Wieck wrote: > Marc G. Fournier wrote: > > On Sun, 16 May 2004, Bruce Momjian wrote: > > > >> I personally don't think Win32 is enough of a new feature either, but > >> others disagree. > > > > Jan, correct me if I'm wrong ... Jan's point is that we have enough > > already to warrant a beta on June 1st, even without Win32 ... Win32 (or > > any of the other stuff, like PITR/tablespaces) would be icing on the cake > > ... > > I agree that we don't have many of the "big marketing bang for the buck" > features done for 7.5. But that is no reason to use wordings like "nifty That was my only point, that we don't have any "big marketing bang for the buck" features. I don't mean to minimize the good work we have already done. -- 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, Pennsylvania19073
On Mon, 17 May 2004, Bruce Momjian wrote: > > Most hopefully this is very discouraging! Connection pools are a nice > > thing and I have used pgpool recently with great success, for pooling > > connections. But attempting to deliver multimaster replication as a > > byproduct of a connection pool isn't going to become an enterprise > > feature. And the more half-baked, half-functional and half-reliable > > replication attempts there are, the harder it will be to finally get a > > real solution being recognized. > > Well, considering we offer _nothing_ for multi-master right now, I think > it is a valuable project. Connection pooling is *not* multi master ... it doesn't even simulate multi-master ... multi-master, at least as far as I'm aware, means "no point of failure", and connection pooling creates a *single* point of failure ... the pgpool process dies, you've lost all connections to the database ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 17 May 2004, Bruce Momjian wrote: > > > > Most hopefully this is very discouraging! Connection pools are a nice > > > thing and I have used pgpool recently with great success, for pooling > > > connections. But attempting to deliver multimaster replication as a > > > byproduct of a connection pool isn't going to become an enterprise > > > feature. And the more half-baked, half-functional and half-reliable > > > replication attempts there are, the harder it will be to finally get a > > > real solution being recognized. > > > > Well, considering we offer _nothing_ for multi-master right now, I think > > it is a valuable project. > > Connection pooling is *not* multi master ... it doesn't even simulate > multi-master ... multi-master, at least as far as I'm aware, means "no > point of failure", and connection pooling creates a *single* point of > failure ... the pgpool process dies, you've lost all connections to the > database ... I think people are confusing pgpool with pgcluster. -- 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, Pennsylvania19073
> > Interesting. > We have made COMPLETELY different experiences. > > There is one question people ask me daily: "When can we have sychronous > replication and PITR?". > Performance is not a problem here. People are more interested in > stability and "enterprise" features such as those I have mentioned above. I doubt that. Having deployed several 7.4 databases, the first customers ask (of course not in technical speech, but in the meaning) when the problem with checkpoint hogging system down is solved. This is a really serious issue, especially when using drbd + ext3. The system will become really unresponsive when checkpoint is running. I heavily await 7.5 because of the background writer.
Mario Weilguni wrote: >> Interesting. We have made COMPLETELY different experiences. >> >> There is one question people ask me daily: "When can we have >> sychronous replication and PITR?". Performance is not a problem >> here. People are more interested in stability and "enterprise" >> features such as those I have mentioned above. > > > I doubt that. Having deployed several 7.4 databases, the first > customers ask (of course not in technical speech, but in the > meaning) when the problem with checkpoint hogging system down is > solved. This is a really serious issue, especially when using > drbd + ext3. The system will become really unresponsive when > checkpoint is running. > > I heavily await 7.5 because of the background writer. This thread reminds me of Andrew Sullivan's signature: The plural of anecdote is not data - Roger Brinner Of course, once the sample size becomes sufficiently large, it does become data. Has the advocacy group performed any polling in this area that might shed some light as to what users and potential users might want? Mike Mascari
On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote: > It is too late to think about pushing back another month. We had this > discussion already. June 1 is it. > I think I have to reiterate: PITR won't make 1 June. (I will be away travelling soon). This has been said a number of times. This is all rather disheartening, having laid out a time plan months back, noting some of this. Yes, I am working on it, and no, I'm not hand waving, but I do take time off every million keystrokes or so. Mid to late June is a realistic time for the completion of PITR, given the additional features I am now working on and the time allocation I can reasonably give this (which in many ways is already unreasonable). My last publicly stated completion estimate was right to within a few days (mid-April, stated in early March). I'm a very task focused person and I strongly support the notion of deadlines and freezes. It's just in this instance, 1 June seems to have been plucked from the air - unless there are other pressures that others can see better than I. What are they again? 7.5dev is loads better than 7.4, though that was true in February. Having waited until now, why not wait for the features? If somebody suggested that we do 7.5 now and then 8.0 with Win32 & PITR in September, I'd think about that, but I'm worried that the next major release is a long way out after this next one, not a few months. Beta is gonna take ages anyhow. Many people in the community are still using 7.3 or below. If the releases come too frequently, running an initdb is just a pain, especially with out a "big reason" to sell to the business folks as to why they have to put up with the downtime of upgrading (or time spent on clever plans). "Is it running? Yeh. So why upgrade?" for existing users, and "Does it have feature XYZ? No, but they think next release. OK, well, we'll wait for that and then trial it" for new adopters. Shipping too early is a bad thing too. It's not clear to me why you would ship in a hurry when the community has waited years to get some of the features on the URGENT list. Honestly, how long has PITR been brewing? And, who thinks that we'll get increased adoption without the big ticket items? (Even if your opinion is that PITR isn't one of them). I can't complete by 1 June. Think worse of me if you choose. Best Regards, Simon Riggs
Hans-Jürgen Schönig wrote: > Somebody has posted sync multimaster replication (PgCluster) - nobody > has commented on that. Maybe I am the only one who has ever tried it ... I didn't find it on pgFoundry, others place to look at it ? Regards Gaetano Mendola
Bruce Momjian wrote: > Marc G. Fournier wrote: >> On Mon, 17 May 2004, Bruce Momjian wrote: >> >> > > Most hopefully this is very discouraging! Connection pools are a nice >> > > thing and I have used pgpool recently with great success, for pooling >> > > connections. But attempting to deliver multimaster replication as a >> > > byproduct of a connection pool isn't going to become an enterprise >> > > feature. And the more half-baked, half-functional and half-reliable >> > > replication attempts there are, the harder it will be to finally get a >> > > real solution being recognized. >> > >> > Well, considering we offer _nothing_ for multi-master right now, I think >> > it is a valuable project. >> >> Connection pooling is *not* multi master ... it doesn't even simulate >> multi-master ... multi-master, at least as far as I'm aware, means "no >> point of failure", and connection pooling creates a *single* point of >> failure ... the pgpool process dies, you've lost all connections to the >> database ... > > I think people are confusing pgpool with pgcluster. > And you wonder where that's coming from, eh? Tatsuo is advertising pgpool as a synchronous replication system suitable for failover. Quoting from the pgpool-1.0 README: pgpool could be used as a replication server. This allows real-time backuping of the database to avoid disk failures.pgpool sends exactly same query to each PostgreSQL servers to accomplish replication. So pgpool can be regardedas a "synchronous replication server". Don't get me wrong, as said pgpool works great for the purpose I tested, the pooling. But statements like that are causing the confusion here. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Simon Riggs wrote: > On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote: > > >>It is too late to think about pushing back another month. We had this >>discussion already. June 1 is it. >> > Just to throw in my .02, plPerlNG won't be ready for testing until mid, later June either. Then there is also plPHP which although we haven't had any bug reports still needs some more peer review. Also we would like to submit our ECPG which includes SET DESCRIPTOR and error handling but that too needs more peer review. It just seems, considering the current state of 7.4.2 (stable, just now being deployed in production shops) that we should make a longer development time for 7.5. Personally, Win32, subtransactions and PITR are what we are after. Second would be inclusion of plPHP and plPerlNG which are arguably the most widely used languages to connect to PostgreSQL. Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
On Mon, 17 May 2004, Joshua D. Drake wrote: > Personally, Win32, subtransactions and PITR are what we are after. > Second would be inclusion of plPHP and plPerlNG which are arguably the > most widely used languages to connect to PostgreSQL. plPHP and plPerlNG both belong on pgfoundry, not in the core distribution ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Mario Weilguni wrote: >>Interesting. >>We have made COMPLETELY different experiences. >> >>There is one question people ask me daily: "When can we have sychronous >>replication and PITR?". >>Performance is not a problem here. People are more interested in >>stability and "enterprise" features such as those I have mentioned above. > > > I doubt that. Having deployed several 7.4 databases, the first customers ask > (of course not in technical speech, but in the meaning) when the problem with > checkpoint hogging system down is solved. This is a really serious issue, > especially when using drbd + ext3. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Well that seems to be part of the problem. ext3 does not scale well at all under load. You should probably upgrade to a better FS (like XFS). I am not saying that your point isn't valid (it is) but upgrading to a better FS will help you. Sincerely, Joshua D. Drake The system will become really unresponsive > when checkpoint is running. > > I heavily await 7.5 because of the background writer. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
Mario Weilguni wrote: >> >> Interesting. >> We have made COMPLETELY different experiences. >> >> There is one question people ask me daily: "When can we have sychronous >> replication and PITR?". >> Performance is not a problem here. People are more interested in >> stability and "enterprise" features such as those I have mentioned above. > > I doubt that. Having deployed several 7.4 databases, the first customers ask > (of course not in technical speech, but in the meaning) when the problem with > checkpoint hogging system down is solved. This is a really serious issue, > especially when using drbd + ext3. The system will become really unresponsive > when checkpoint is running. > > I heavily await 7.5 because of the background writer. Have you done some more extensive tests with 7.5 already and if so, what are your experiences with it so far? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> > plPHP and plPerlNG both belong on pgfoundry, not in the core distribution > ... Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? Sincerely, Joshua D. Drake > > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
Simon Riggs <simon@2ndquadrant.com> writes: > I can't complete by 1 June. Think worse of me if you choose. I'll mention another perspective as a user. I'm actually happier seeing a relatively minor release come out just before the big changes hit. If 7.5 has Windows, PITR, nested transactions, etc. especially if I see they went in just before a feature freeze then I'm liable to wait before I suggest installing it in production because it makes me fear the impact these major new features will have on a system that's been running fine on 7.4. Whereas if 7.5 comes out and is an incremental improvement over 7.4 with a background writer, more knobs to control checkpoints and vacuum, better sorted pg_dumps, etc, then I'm liable to install it right away. And I get to use these features while the big changes settle. From a user-perceptions point of view this is an even bigger factor when people start bandying about 8.0. A LOT of sysadmins are going to hold off on installing a release labelled 8.0 until they see 8.1 or 8.2. Sysadmins are an awfully superstitious bunch and numerology is popular. Moreover if PITR, the Windows port, nested transactions go into 7.6 or 8.0 right at the beginning of the development cycle and we have 3-4 months of working with databases running with these features I strongly suspect that the stability of the product will make a bigger long term impression than the rapid pace of new features arriving. So in my perfect world I picture 7.5 freezing June 1 and releasing in July or so, giving a nice reliable simple upgrade for people who just want a safe 7.x series to upgrade to even after 8.0 comes out. PITR, nested transactions going into the CVS tree sometime in June or July and being frozen as 8.0 towards the end of the year. -- greg
On Mon, 17 May 2004, Joshua D. Drake wrote: > > > > > plPHP and plPerlNG both belong on pgfoundry, not in the core distribution > > ... > > Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to > replace plPerl, I was talking with Bruce and he seemed to think that (as > long as the code was good enough) that we could incorporate plPHP??? That is the plan ... unless someone knows a reason why they can't be built independently of the core? ecpg relies on the grammar files in core, but as far as I knew (please correct me if I'm wrong) the pls only rely on headers and libraries that get installed ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Greg Stark wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > >>I can't complete by 1 June. Think worse of me if you choose. > ... > So in my perfect world I picture 7.5 freezing June 1 and releasing in July or > so, giving a nice reliable simple upgrade for people who just want a safe 7.x > series to upgrade to even after 8.0 comes out. PITR, nested transactions going > into the CVS tree sometime in June or July and being frozen as 8.0 towards the > end of the year. A quick google of "7.4 Win32 release" will reveal that the above was precisely what was said about 7.4: it would be released to not hold up important features like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost as if a cron job reposts this thread every 6 - 12 months. For those of us that are desirous of PITR, it's a 6 month reposting that is becoming painful to read... Mike Mascari
Mike Mascari <mascarm@mascari.com> writes: > Greg Stark wrote: > > Simon Riggs <simon@2ndquadrant.com> writes: > > > >>I can't complete by 1 June. Think worse of me if you choose. > > > ... > > So in my perfect world I picture 7.5 freezing June 1 and releasing in July or > > so, giving a nice reliable simple upgrade for people who just want a safe 7.x > > series to upgrade to even after 8.0 comes out. PITR, nested transactions going > > into the CVS tree sometime in June or July and being frozen as 8.0 towards the > > end of the year. > > A quick google of "7.4 Win32 release" will reveal that the above was precisely > what was said about 7.4: it would be released to not hold up important features > like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost > as if a cron job reposts this thread every 6 - 12 months. For those of us that > are desirous of PITR, it's a 6 month reposting that is becoming painful to > read... I'm not sure what your point is though. It's not like people with my attitude made the people writing code take any longer. In fact had we held off 7.4 for any of these features it would have been a disaster. Incidentally, I'm not suggesting rushing 7.6/8.0 out the door. I'm imagining a regular release cycle. My comments are more geared to the idea that having PITR, Nested Transactions, etc hit the tree early in the development cycle would be smoother than having them hit right at the end of the development cycle. Think of all the added bells and whistles PITR will be able to grow over the course of a whole release cycle. Instead of having a barebones "see it works" implementation we'll have a really polished system with lots of optional but appreciated features. Maybe better integration in third-party backup tools, maybe even standby databases or replication based on it. -- greg
On Mon, 17 May 2004, Mike Mascari wrote: > Greg Stark wrote: > > Simon Riggs <simon@2ndquadrant.com> writes: > > > >>I can't complete by 1 June. Think worse of me if you choose. > > > ... > > So in my perfect world I picture 7.5 freezing June 1 and releasing in July or > > so, giving a nice reliable simple upgrade for people who just want a safe 7.x > > series to upgrade to even after 8.0 comes out. PITR, nested transactions going > > into the CVS tree sometime in June or July and being frozen as 8.0 towards the > > end of the year. > > A quick google of "7.4 Win32 release" will reveal that the above was > precisely what was said about 7.4: it would be released to not hold > up important features like the IN optimization and a quick 7.5 would > have Win32 and PITR. It's almost as if a cron job reposts this > thread every 6 - 12 months. For those of us that are desirous of > PITR, it's a 6 month reposting that is becoming painful to read... k, let's think this through ... 7.4 was released, what, 6 months ago? And 6 months later, PITR still isn't ready? Is there some logic here that if 7.4 wasn't released, PITR would have been done any sooner? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 17 May 2004, Joshua D. Drake wrote: > >> Personally, Win32, subtransactions and PITR are what we are after. >> Second would be inclusion of plPHP and plPerlNG which are arguably the >> most widely used languages to connect to PostgreSQL. > > plPHP and plPerlNG both belong on pgfoundry, not in the core distribution > ... When are you going to pull PL/pgSQL, PL/python and PL/Tcl? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Marc G. Fournier wrote: > On Mon, 17 May 2004, Joshua D. Drake wrote: > >> >> > >> > plPHP and plPerlNG both belong on pgfoundry, not in the core distribution >> > ... >> >> Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to >> replace plPerl, I was talking with Bruce and he seemed to think that (as >> long as the code was good enough) that we could incorporate plPHP??? > > That is the plan ... unless someone knows a reason why they can't be built > independently of the core? ecpg relies on the grammar files in core, but > as far as I knew (please correct me if I'm wrong) the pls only rely on > headers and libraries that get installed ... They are not as independant as one might think. The core support for set returning functions is required before a PL can do it. Same was with cursors and same will be with subtransactions being the base for exception handling. People have been struggling with unloadable shared objects from another version due to elog changes, I can't imagine what kind of support horror we're creating with this now. The much I am for pulling stuff that does not belong into core, doing it just for the fun of cleaning up or trimming doesn't do. One of the major functions of CVS is that one can tag collections of revisions that together build a release, a "known to be working snapshot of file revisions". If we completely lose the ability to tell what version of what PL, client interface or extension works with what version of the backend, we're losing some important detail here. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
> Bruce Momjian wrote: > > Marc G. Fournier wrote: > >> On Mon, 17 May 2004, Bruce Momjian wrote: > >> > >> > > Most hopefully this is very discouraging! Connection pools are a nice > >> > > thing and I have used pgpool recently with great success, for pooling > >> > > connections. But attempting to deliver multimaster replication as a > >> > > byproduct of a connection pool isn't going to become an enterprise > >> > > feature. And the more half-baked, half-functional and half-reliable > >> > > replication attempts there are, the harder it will be to finally get a > >> > > real solution being recognized. > >> > > >> > Well, considering we offer _nothing_ for multi-master right now, I think > >> > it is a valuable project. > >> > >> Connection pooling is *not* multi master ... it doesn't even simulate > >> multi-master ... multi-master, at least as far as I'm aware, means "no > >> point of failure", and connection pooling creates a *single* point of > >> failure ... the pgpool process dies, you've lost all connections to the > >> database ... I think multi-master does nothing with free-from-single-point-of-failure. A multi-master replication system could have its own single point of failure (for example, some systems have single "coordinate server"). On the other hand single-master replication system could avoid single point of failure using some external mechanism (for example UltraMonkey). > > I think people are confusing pgpool with pgcluster. > > > > And you wonder where that's coming from, eh? Tatsuo is advertising > pgpool as a synchronous replication system suitable for failover. > Quoting from the pgpool-1.0 README: Please do not use the word "failover" for pgpool relication functionality. "Failover" means it could continue replication operation with alternative database. pgpool does not do that in replication mode. Instead it disconnect the failed DB and continues operation with healthy DB (with no replication, of course). That's why I use the word "degeneration" in pgpool's replication mode. > pgpool could be used as a replication server. This allows real-time > backuping of the database to avoid disk failures. pgpool sends > exactly same query to each PostgreSQL servers to accomplish > replication. So pgpool can be regarded as a "synchronous > replication server". > > Don't get me wrong, as said pgpool works great for the purpose I tested, > the pooling. But statements like that are causing the confusion here. Could you tell me why above is confusing? If it's really confusing, I'm glad to enhance it. Or are you saying pgpool should not be regrard as having "replicaton facility"? Or you are saying that pgpool is too similar to PGCluster? PGCluster is a multi-master/multi-slave/sync relication system. pgpool is a single-master/single-slave/sync replication. There's a clear distinction. single vs. multi-master is a BIG difference and I have never stated that pgpool is a multi-master replication system. BTW, the reason why I developed pgpool with replication functionality is that there's no single perfect replication solution in the world. Here are my comments for officially released replicatin systems (from my own point of view, of course): 1) DBMirror: good: simple and easy to use. bad: can not handle too much traffic. cannot replicate large objects. 2) PGCluster: good: can handle failover and recovery. SELECT load balancing is really nice. bad: requries many PCs. update performance is not good. cannot replicate large objects. 3) pgpool: good: simple and easy to use. can replicate large objects. update performance is not too bad. bad: noload balancing, no failover. I'm interested in if Slony-I solves all these "bad". I will try it when I have spare time. -- Tatsuo Ishii
> The much I am for pulling stuff that does not belong into core, doing > it just for the fun of cleaning up or trimming doesn't do. One of the > major functions of CVS is that one can tag collections of revisions > that together build a release, a "known to be working snapshot of file > revisions". If we completely lose the ability to tell what version of > what PL, client interface or extension works with what version of the > backend, we're losing some important detail here. > Also, one of the best features of PostgreSQL is that you can, at will write a procedure in just about anything... It seems that keeping at least the most popular pl implementations would be an important step. ] > > Jan > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Joshua D. Drake wrote: > Just to throw in my .02, plPerlNG won't be ready for testing until mid, > later June either. Then there is also plPHP which although we haven't > had any bug reports still needs some more peer review. > > Also we would like to submit our ECPG which includes SET DESCRIPTOR and > error handling but that too needs more peer review. I assume your ecpg will be a patch to the existing ecpg rather than a new verion, right? -- 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, Pennsylvania19073
> He is waiting for nested transactions to be committed so he can merge > his work in. > > >>Somebody has posted sync multimaster replication (PgCluster) - nobody >>has commented on that. Maybe I am the only one who has ever tried it ... > > > I think it should be on gborg. You mean pgFoundry :) Chris
Marc G. Fournier wrote: > On Mon, 17 May 2004, Joshua D. Drake wrote: > > > > > > > > > plPHP and plPerlNG both belong on pgfoundry, not in the core distribution > > > ... > > > > Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to > > replace plPerl, I was talking with Bruce and he seemed to think that (as > > long as the code was good enough) that we could incorporate plPHP??? > > That is the plan ... unless someone knows a reason why they can't be built > independently of the core? ecpg relies on the grammar files in core, but > as far as I knew (please correct me if I'm wrong) the pls only rely on > headers and libraries that get installed ... Server-side languages are tied into the backend even closer than the user data types. They are best in the core distribution. We didn't put plR in core because it had a conflicting license. -- 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, Pennsylvania19073
<br /><blockquote cite="mid200405180120.i4I1KU429838@candle.pha.pa.us" type="cite"><pre wrap=""> I assume your ecpg will be a patch to the existing ecpg rather than a new verion, right? </pre></blockquote> Yes it is a patch against 7.4.2<br /><br /><br /><br /> J<br /><br /><br /><br /><pre class="moz-signature"cols="72">-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a> PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>
On Mon, 17 May 2004, Jan Wieck wrote: > They are not as independant as one might think. The core support for set > returning functions is required before a PL can do it. Same was with > cursors and same will be with subtransactions being the base for > exception handling. People have been struggling with unloadable shared > objects from another version due to elog changes, I can't imagine what > kind of support horror we're creating with this now. k, how is this different then any other software package that has to be extended to make use of new features? For instance, when subtransactions get added, is that same person going to extended the various pls as well? Or, more likely, when subtransactions are added, will someone responsible for each of the pls submit patches to extend them? Having pl/pgsql included as a 'reference implementation' is reasonable ... I just think that pl/<pick your language here> should be on pgfoundry ... > If we completely lose the ability to tell what version of what PL, > client interface or extension works with what version of the backend, > we're losing some important detail here. Why is it our responsibility to ensure that though? Shouldn't the developer (or group of developers) responsible for the PL/interface/extension be responsible for that? Let's use plPHP as an example here ... I'm going to guess that it supports PHP4, which is the 'standard' right now ... what about PHP5? If not, what happens in 3 months if/when that support is added? Do ppl using PHP5 have to wait until the next release of PostgreSQL before they can use it? If, instead, plPHP is on pgfoundry, there is nothing that stops them adopting a release numbering in parallel to the core distribution, at least in so far as major.minor ... but they could release a major.minor.minor release as required seperate from our release cycle that still matches our latest stable, but extends itself to working with PHP5, as an example ... The thing is, whether as part of core, or as a seperate project, *any* pl/interface/extension has to be maintained in order to be in sync ... if done as a seperate project, in parallel with core, it is at least possible to release on their own timelines in order to correct bugs, or add features ... as part of core, new features/bug fixes have to wait for all of core to be released ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 17 May 2004, Mike Mascari wrote: > >>A quick google of "7.4 Win32 release" will reveal that the above was >>precisely what was said about 7.4: it would be released to not hold >>up important features like the IN optimization and a quick 7.5 would >>have Win32 and PITR. It's almost as if a cron job reposts this >>thread every 6 - 12 months. For those of us that are desirous of >>PITR, it's a 6 month reposting that is becoming painful to read... > > k, let's think this through ... 7.4 was released, what, 6 months ago? And > 6 months later, PITR still isn't ready? Is there some logic here that if > 7.4 wasn't released, PITR would have been done any sooner? Not being the author, I don't know. And in the case of PITR, the pre-7.4 author is different than the post-7.4 author. However, if I was personally responsible for holding up the release of a project due to a feature that I had vowed to complete, I would feel morally compelled to get it done. If I had then asked for, and was granted, an extra 15-30 days I would feel even more personally responsible and under greater pressure. If, however, the project made the release without waiting, I would feel simultaneously relieved and possibly a little bitter. Possibly a little bitter in that either what I was working on wasn't perceived as sufficiently valuable to hold up a release for 15-30 days, or that my word regarding the completion status was insufficient for the project to trust me. Let me reiterate the words "possibly" and "little." But in open source projects, a developer willing to contribute hundreds, possibly thousands of hours of his own time is particularly invaluable. I can tell you that, in economic models that have studied human behavior with respect to unemployment insurance, for example, the re-employment rates are clustered at the tails: when someone is first unemployed and when the insurance is about to expire. It's an inappropriate analogy because the project lives on from release to release, instead of having a drop-dead date at which point no future changes would be made ad infinitum, but it paints a useful picture. I'm willing to bet that CVS commit rates mirror the above behavior. Unlike unemployment benefits, releasing the software without the feature essentially just extends the development period another 6 months, the work will intensify at the new perceived tails, and the process repeated. There are probably econometric papers that model the software development release cycle that could give quantitative arguments. I'm not arguing I'm right and your wrong, btw. I'm just pointing out some of the possibilities. In fact, for one developer it might be the "code production maximizing condition" to give them another 6 months and for another, creating the pressure associated with a 15-30 day extension where the world is standing still awaiting their patch... Mike Mascari
On Mon, 17 May 2004, Joshua D. Drake wrote: > > > > >I assume your ecpg will be a patch to the existing ecpg rather than a > >new verion, right? > > > > > > > Yes it is a patch against 7.4.2 Will you have one against -HEAD? I believe there have been changes since 7.5 was branched, no? Or have they been mostly cosmetic/docs? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 17 May 2004, Bruce Momjian wrote: > Server-side languages are tied into the backend even closer than the > user data types. They are best in the core distribution. We didn't put > plR in core because it had a conflicting license. So, they can live on their own, which is a good thing to know ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 17 May 2004, Joshua D. Drake wrote: > > > > > > > > >I assume your ecpg will be a patch to the existing ecpg rather than a > > >new verion, right? > > > > > > > > > > > Yes it is a patch against 7.4.2 > > Will you have one against -HEAD? I believe there have been changes since > 7.5 was branched, no? Or have they been mostly cosmetic/docs? Josh just sent me the patch and it looks good. I encouraged him to send it over to Michael Meskes, and soon, especially if he wants it in 7.5. -- 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, Pennsylvania19073
>Why is it our responsibility to ensure that though? Shouldn't the >developer (or group of developers) responsible for the >PL/interface/extension be responsible for that? > >Let's use plPHP as an example here ... I'm going to guess that it supports >PHP4, which is the 'standard' right now ... what about PHP5? If not, what >happens in 3 months if/when that support is added? Do ppl using PHP5 have >to wait until the next release of PostgreSQL before they can use it? > > > Actually this is a pretty good example. Yes right now it supports PHP4, it will support PHP5 when PHP5 is ready. And of course, no they would not have to wait. They could download and patch against the current source tree... >The thing is, whether as part of core, or as a seperate project, *any* >pl/interface/extension has to be maintained in order to be in sync ... if >done as a seperate project, in parallel with core, it is at least >possible to release on their own timelines in order to correct bugs, or >add features ... as part of core, new features/bug fixes have to wait for >all of core to be released ... > > > Well actually no, because of the above mentioned. Even if plPHP is on pgFoundry... there is no reason why a README couldn't be included in the src/pl/plphp directory that says: look here for the latest release etc... Sincerely, Joshua D. Drake >---- >Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > >---------------------------(end of broadcast)--------------------------- >TIP 8: explain analyze is your friend > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Bruce Momjian said: > Marc G. Fournier wrote: >> On Mon, 17 May 2004, Joshua D. Drake wrote: >> >> > >> > > >> > > plPHP and plPerlNG both belong on pgfoundry, not in the core >> > > distribution ... >> > >> > Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed >> > to replace plPerl, I was talking with Bruce and he seemed to think >> > that (as long as the code was good enough) that we could incorporate >> > plPHP??? >> >> That is the plan ... unless someone knows a reason why they can't be >> built independently of the core? ecpg relies on the grammar files in >> core, but as far as I knew (please correct me if I'm wrong) the pls >> only rely on headers and libraries that get installed ... > > Server-side languages are tied into the backend even closer than the > user data types. They are best in the core distribution. We didn't > put plR in core because it had a conflicting license. > I would never have created the plperlNG project on pgfoundry if I had thought it meant divorcing plperl from the core. pgfoundry in my mind can be a home for projects that will eventually fold into the core, as well as things that will always remain separate. I agree with Bruce about the place of server-side PLs. cheers andrew
Marc G. Fournier wrote: > > A quick google of "7.4 Win32 release" will reveal that the above was > > precisely what was said about 7.4: it would be released to not hold > > up important features like the IN optimization and a quick 7.5 would > > have Win32 and PITR. It's almost as if a cron job reposts this > > thread every 6 - 12 months. For those of us that are desirous of > > PITR, it's a 6 month reposting that is becoming painful to read... > > k, let's think this through ... 7.4 was released, what, 6 months ago? And > 6 months later, PITR still isn't ready? Is there some logic here that if > 7.4 wasn't released, PITR would have been done any sooner? Even though I was for a later feature freeze, Marc argument is powerful. There was talk that Win32 and PITR would be available right after 7.5 started development, and they weren't. Instead it took several months for Patrick and Tom to get JR's PITR/WAL patch into CVS, and then another month or two for someone to appear and do the work of archiving the files, then after discussion of implementation issues, it now needs even more work. Win32 has been on a steady course thanks to Claudio and Magnus --- without them we would be nowhere near finished. Nested transactions were started in April and tablespaces in February, both funded by Fujitsu. Basically, maybe Marc is right that these features have to span multiple releases. Win32 spanned two releases (some of it was in 7.4). PITR WAL was initially done by JR just before 7.3 feature freeze, I think, but it took all this time to get this far. Basically, my big concern is "incremental improvement" releases, which I feel describe our past few releases. Yes, I said it. I see items listed above as critical to allowing PostgreSQL to move into more significant roles in enterprises, and I am frustrated that it is taking so long to happen. What can be done? Well, money from Fujitsu and other companies (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit some of these bigger items, so hopefully that will move us forward in these complex areas. I am not sure what could have been done to push some of these projects along faster. I am happy Win32 had a steady pace of improvement, but even now we are finishing up to the wire rather than having it done months ago, but in hindsight, I am not sure what we could have done differently. So, yea, I am frustrated. I know these features are hard and complex, but I want them for PostgreSQL, and I want them as soon as possible. I guess what really bugs me is that we are so close to having these few remaining big features, and because they are so complex, they are taking a lot longer to arrive than previous features, and sometimes see a year pass without progress on some items, and that bugs me. -- 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, Pennsylvania19073
On Mon, May 17, 2004 at 17:06:18 -0400, Greg Stark <gsstark@mit.edu> wrote: > > I'll mention another perspective as a user. I'm actually happier seeing a > relatively minor release come out just before the big changes hit. If 7.5 has > Windows, PITR, nested transactions, etc. especially if I see they went in just > before a feature freeze then I'm liable to wait before I suggest installing it > in production because it makes me fear the impact these major new features > will have on a system that's been running fine on 7.4. 7.5 has already had some significant changes made in how writes are done to disk. If I had very valuable data to protect I would already consider 7.5 a risky upgrade (in comparison to the 7.3 to 7.4 upgrade). If this is your situation, going to 7.4.3 and sticking with it for a while waiting to see how 7.5 does, may be a good idea.
>So, yea, I am frustrated. I know these features are hard and complex, >but I want them for PostgreSQL, and I want them as soon as possible. I >guess what really bugs me is that we are so close to having these few >remaining big features, and because they are so complex, they are taking >a lot longer to arrive than previous features, and sometimes see a year >pass without progress on some items, and that bugs me. > > > So why do we wait for some of these features? The bgwriter is done right? Why don't we backport to 7.4.x and release with 7.4.3? What about the vacuum stuff Jan was doing? I guess what I am saying is, what features are in HEAD that can be backported to 7.4.x without the requiring of an initdb? Yes it would be breaking from the tradition of very little feature releases in incrementals but then again maybe that would be a good thing... Sincerely, Joshua D. Drkae -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
On Mon, 17 May 2004, Joshua D. Drake wrote: > > >So, yea, I am frustrated. I know these features are hard and complex, > >but I want them for PostgreSQL, and I want them as soon as possible. I > >guess what really bugs me is that we are so close to having these few > >remaining big features, and because they are so complex, they are taking > >a lot longer to arrive than previous features, and sometimes see a year > >pass without progress on some items, and that bugs me. > > > > > > > So why do we wait for some of these features? The bgwriter is done > right? Why don't we backport to 7.4.x and release with 7.4.3? What about > the vacuum stuff Jan was doing? > > I guess what I am saying is, what features are in HEAD that can be > backported to 7.4.x without the requiring of an initdb? > > Yes it would be breaking from the tradition of very little feature > releases in incrementals but then again maybe that would be a good > thing... This has been put forward by me a couple of times in the past, and, to a small extent, I do agree with the arguments against it ... namely, the backporting, testing and release cycles that we'd have to adopt would detract from forward development ... As soon as we get to backporting features, then we have to get into feature freezes on the "stable" branch, beta periods of testing leading to a release, etc ... I'd almost say that time would be better spent on coming up with an effective upgrade method so that upgrading to new releases is easier ... Please note that I'm not against the backporting, but do understand the arguments against it in terms of time and manpower ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> Not being the author, I don't know. And in the case of PITR, the pre-7.4
> author is different than the post-7.4 author. However, if I was
> personally responsible for holding up the release of a project due to a
> feature that I had vowed to complete, I would feel morally compelled to
> get it done. If I had then asked for, and was granted, an extra 15-30
> days I would feel even more personally responsible and under greater
> pressure.
>
> If, however, the project made the release without waiting, I would feel
> simultaneously relieved and possibly a little bitter. Possibly a little
> bitter in that either what I was working on wasn't perceived as
> sufficiently valuable to hold up a release for 15-30 days, or that my
> word regarding the completion status was insufficient for the project to
> trust me. Let me reiterate the words "possibly" and "little." But in
> open source projects, a developer willing to contribute hundreds,
> possibly thousands of hours of his own time is particularly invaluable.
>
> I can tell you that, in economic models that have studied human behavior
> with respect to unemployment insurance, for example, the re-employment
> rates are clustered at the tails: when someone is first unemployed and
> when the insurance is about to expire. It's an inappropriate analogy
> because the project lives on from release to release, instead of having
> a drop-dead date at which point no future changes would be made ad
> infinitum, but it paints a useful picture. I'm willing to bet that CVS
> commit rates mirror the above behavior.
>
> Unlike unemployment benefits, releasing the software without the feature
> essentially just extends the development period another 6 months, the
> work will intensify at the new perceived tails, and the process
> repeated. There are probably econometric papers that model the software
> development release cycle that could give quantitative arguments. I'm
> not arguing I'm right and your wrong, btw. I'm just pointing out some of
> the possibilities. In fact, for one developer it might be the "code
> production maximizing condition" to give them another 6 months and for
> another, creating the pressure associated with a 15-30 day extension
> where the world is standing still awaiting their patch...
>
> Mike Mascari
Yesterday I have issued a posting which had to do with "motivation".
This is Open Source - there is no boss which tells somebody to finish
something. Therefore we must MOTIVATE people.
Has anybody read Sim Riggs posting earlier in the thread.
There is one paragraph which makes my alarm bells ring VERY LOUD:
"This is all rather disheartening, having laid out a time plan months
back, noting some of this. Yes, I am working on it, and no, I'm not hand
waving, but I do take time off every million keystrokes or so."
If somebody who has done a GREAT JOB is disheartened by the way his work
is treated it is really time to start thinking ...
From my very personal point of view Mike absolutely right; why not give
it a try. I guess Simon and Alvaro deserve some more time and we should
give those guys a limited time frame to finish their work.
Recall, it's all about motivation ...
Regards,
Hans
--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
Am Monday 17 May 2004 22:42 schrieb Jan Wieck: > > I doubt that. Having deployed several 7.4 databases, the first customers ask > > (of course not in technical speech, but in the meaning) when the problem with > > checkpoint hogging system down is solved. This is a really serious issue, > > especially when using drbd + ext3. The system will become really unresponsive > > when checkpoint is running. > > > > I heavily await 7.5 because of the background writer. > > Have you done some more extensive tests with 7.5 already and if so, what > are your experiences with it so far? Not really yet, I've installed 7.5 on a development machine yesterday, changed to JFS filesystem, and so far the system feels more responsive, but I've yet to test it. 7.5 on my personal PC performed very fine, especially with some more problematic queries it produced better query plans. Regards,Mario Weilguni
> > Well that seems to be part of the problem. ext3 does not scale well at > all under load. You should probably upgrade to a better FS (like XFS). I > am not saying that your point isn't valid (it is) but upgrading to a > better FS will help you. > Thanks for the info, but I've already noticed that. XFS is no option since it does not work with drbd, but jfs seems to be quite good. Regards, Mario Weilguni
>From the FAQ (http://www.drbd.org/316.html): Q: Can XFS be used with DRBD? A: XFS uses dynamic block size, thus DRBD 0.7 or later is needed. Hope we're talking about the same project. ;) Cheers! On Tue, 2004-05-18 at 00:16, Mario Weilguni wrote: > > > > Well that seems to be part of the problem. ext3 does not scale well at > > all under load. You should probably upgrade to a better FS (like XFS). I > > am not saying that your point isn't valid (it is) but upgrading to a > > better FS will help you. > > > > Thanks for the info, but I've already noticed that. XFS is no option since it does not work with drbd, > but jfs seems to be quite good. > > Regards, > Mario Weilguni > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings -- Greg Copeland, Owner greg@copelandconsulting.net Copeland Computer Consulting 940.206.8004
Am Tuesday 18 May 2004 07:40 schrieb Greg Copeland: > >From the FAQ (http://www.drbd.org/316.html): > > Q: Can XFS be used with DRBD? > > > A: XFS uses dynamic block size, thus DRBD 0.7 or later is needed. > > Hope we're talking about the same project. ;) Hmmm, interesting. But I did not find 0.7 on the history page http://www.drbd.org/releases.html maybe it's not release status yet - thus no option for now. Regards,Mario Weilguni
Marc G. Fournier wrote: > That is the plan ... unless someone knows a reason why they can't be > built independently of the core? How about this one: Everything we have moved from the core to gborg so far has been a miserable failure. The code is no longer maintained, or maintained by three different competing groups, the documentation has disappeared, the portability is no longer taken care of, and only the bravest souls even dare look at the stuff. I think before you move anything more, you need to have a strong, convincing community on the receiving side rather than just kicking things out and hoping someone will pick it up. Just because it can be built separately doesn't mean everything needs to be.
Joshua D. Drake wrote: > Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to > replace plPerl, I was talking with Bruce and he seemed to think that > (as long as the code was good enough) that we could incorporate > plPHP??? One reason against including plPHP in the core would be that it would create a circular build dependency between the packages postgresql and php. I think we should rather avoid that.
> How about this one: Everything we have moved from the core to gborg so > far has been a miserable failure. The code is no longer maintained, or > maintained by three different competing groups, the documentation has > disappeared, the portability is no longer taken care of, and only the > bravest souls even dare look at the stuff. I think before you move > anything more, you need to have a strong, convincing community on the > receiving side rather than just kicking things out and hoping someone > will pick it up. Just because it can be built separately doesn't mean > everything needs to be. Above looks quite true for me too. -- Tatsuo Ishii
Peter Eisentraut wrote: > How about this one: Everything we have moved from the core to gborg so > far has been a miserable failure. The code is no longer maintained, or > maintained by three different competing groups, the documentation has > disappeared, the portability is no longer taken care of, and only the > bravest souls even dare look at the stuff. I think before you move > anything more, you need to have a strong, convincing community on the > receiving side rather than just kicking things out and hoping someone > will pick it up. Just because it can be built separately doesn't mean > everything needs to be. I guess the key thing is that pgFoundry shouldn't be a community distinct from the core. The same community standards need to apply on both sides of the fence. What has happened here echoes the experiences of the PHP project very closely. PHP, too, thought that the core was getting too big for efficient release coordination, and started moving extensions to PECL, an extension library bolted on the side of PEAR. Trouble is, nobody wants to be forced into the ghetto. The only way to make pgFoundry work is to minimize the downside of living there. Consider these: - Don't move just "inessential" projects. Move absolutely essential projects to push end-user and developer adoption. - Have a tier of "official" projects that are actively endorsed by and within the core distribution. Don't be afraid topick a favorite solution within a class (for example in replication). - Discourage other developers from ignoring pgFoundry projects. For the official tier, this could mean sending commit messagesto pgsql-committers, patches to pgsql-patches, and having the discussions here. Resist the urge to start project-specific mailing lists unless absolutely essential. Have everyone know that the pgFoundry/core distinction onlyexists for release engineering purposes, and that it can't be allowed to split the community. - Invest in integrating pgFoundry tools into the core distribution. For example, official projects should have makefilesincluded in the core that'd download and compile the latest compatible version. Components as important as JDBCand some of the procedural languages could be distributed this way. mk
Marko Karppinen wrote: > > I guess the key thing is that pgFoundry shouldn't be a community > distinct from the core. The same community standards need to apply > on both sides of the fence. [snip] Thanks Marko, you just wrote exactly what I was concerned about with "features" rather than "applications" being in pgfoundry. The only thing I'd add is that we need to separate development from delivery. The important thing as an end-user is not where the CVS is kept or how things are kept in-sync but: 1. Can I get hold of it easily? 2. Is it mentioned in the manual? 3. Do I know whatversions of PG/other it needs? pl/PHP etc might not need to be in the core CVS or tar.gz, but probably do need to be in a pl/ or plugins/ directory on the main site. If it takes a week or two (after release) for the various plugins to appear, that's fine - no-one upgrades a production system on day 1 anyway. Perhaps this is the best way to look at it - when the .rpm's/.deb's are put together what does the community want in them? -- Richard Huxton Archonet Ltd
On Mon, 2004-05-17 at 19:39, Marc G. Fournier wrote:
> On Mon, 17 May 2004, Mike Mascari wrote:
> > Greg Stark wrote:
> > > Simon Riggs <simon@2ndquadrant.com> writes:
> > >
> > >>I can't complete by 1 June. Think worse of me if you choose.
> > >
> > ...
> > > So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
> > > so, giving a nice reliable simple upgrade for people who just want a safe 7.x
> > > series to upgrade to even after 8.0 comes out. PITR, nested transactions going
> > > into the CVS tree sometime in June or July and being frozen as 8.0 towards the
> > > end of the year.
> >
> > A quick google of "7.4 Win32 release" will reveal that the above was
> > precisely what was said about 7.4: it would be released to not hold
> > up important features like the IN optimization and a quick 7.5 would
> > have Win32 and PITR. It's almost as if a cron job reposts this
> > thread every 6 - 12 months. For those of us that are desirous of
> > PITR, it's a 6 month reposting that is becoming painful to read...
>
> k, let's think this through ... 7.4 was released, what, 6 months ago? And
> 6 months later, PITR still isn't ready? Is there some logic here that if
> 7.4 wasn't released, PITR would have been done any sooner?
>
Potentially yes. One thing all of the developers have said they want is
more feedback from some of the more expert developers, but if we go into
feature freeze then the focus of folks like Tom and Bruce will be on
completing release, not on helping out with these new features. We had
the original patch for PITR before 7.4 went into beta IIRC, but it then
had to sit through a lengthy beta process before Tom could do some final
code review and get things committed.
Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any given development effort. If I had to pick (If I got to
pick?), I would rather see Bruce/Tom/Jan working on helping these guys
finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5
branch.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>a release, etc ... > >I'd almost say that time would be better spent on coming up with an >effective upgrade method so that upgrading to new releases is easier ... > >Please note that I'm not against the backporting, but do understand the >arguments against it in terms of time and manpower ... > > I believe they are valid arguments too and if we were to do it we would definately need to be selective about "which" features get back ported but forward movement can be in the present tree as well. Joshua D. Drake >---- >Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Peter Eisentraut wrote:<br /><blockquote cite="mid200405180857.08504.peter_e@gmx.net" type="cite"><pre wrap="">Joshua D.Drake wrote: </pre><blockquote type="cite"><pre wrap="">Uhhh?? Are you ripping out all core pls then? plPerlNG is supposedto replace plPerl, I was talking with Bruce and he seemed to think that (as long as the code was good enough) that we could incorporate plPHP??? </pre></blockquote><pre wrap=""> One reason against including plPHP in the core would be that it would create a circular build dependency between the packages postgresql and php. I think we should rather avoid that. </pre></blockquote> It is no different that the dependency between plPerl andPerl, plPython and Python or worse<br /> plTCL and TCL (which typically isn't installed anymore).<br /><br /> Sincerely,<br/><br /> Joshua D. Drake<br /><br /><pre class="moz-signature" cols="72">-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a> PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>
On Tue, 18 May 2004, Robert Treat wrote: > Just like Bruce has often asked the community how they feel about him > balancing his time between things like speaking engagements and patch > applications, core developers have a limited amount of time they can > spend on any given development effort. If I had to pick (If I got to > pick?), I would rather see Bruce/Tom/Jan working on helping these guys > finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 > branch. Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: > fact that checkpoints, vacuum runs and pg_dumps bog down their machines > to the state where simple queries take several seconds care that much > for any Win32 port? Do you think it is a good sign for those who have Yes. I am one such person, but from the marketing side of things, I understand perfectly well what failing to deliver on Win32 again will cost. It's not important to _me_, but that doesn't mean it's unimportant to the project. A -- Andrew Sullivan | ajs@crankycanuck.ca
Marc G. Fournier wrote: > On Tue, 18 May 2004, Robert Treat wrote: > > > Just like Bruce has often asked the community how they feel about him > > balancing his time between things like speaking engagements and patch > > applications, core developers have a limited amount of time they can > > spend on any given development effort. If I had to pick (If I got to > > pick?), I would rather see Bruce/Tom/Jan working on helping these guys > > finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 > > branch. > > Except you miss one key point here ... if Bruce/Tom/Jan have that sort of > time, why aren't they doing it now? I can answer that one. We only have limited time to help a limited number of folks. I have been Win32-focussed, so haven't had time to help anyone else, and even applying patches has been delayed and folks are complaining. I have talked to Jan about helping me get PITR done. It is very close and Jan said he would work on a patch to help. I think the poster's point was that once we enter feature freeze, we have even less time to help folks, hence no progress in PITR until long after 7.4. -- 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, Pennsylvania19073
On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote: > On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: > > > fact that checkpoints, vacuum runs and pg_dumps bog down their machines > > to the state where simple queries take several seconds care that much > > for any Win32 port? Do you think it is a good sign for those who have > > Yes. I am one such person, but from the marketing side of things, I > understand perfectly well what failing to deliver on Win32 again will > cost. It's not important to _me_, but that doesn't mean it's > unimportant to the project. > My primary fear about delivering Win32 with all of these other great features is that, IMO, there is a higher level of risk associated with these advanced features. At the same time, this will be the first trial for many Win32 users. Should there be some problems, in general, or worse, specific to Win32 users as it relates to these new features, it could cost some serious Win32/PostgreSQL community points. A troubled release which is experienced by Win32 users is going to be a battle cry for MySQL. I've been quietly hoping that these great new features would become available a release before Win32 was completed. That way, a shake down would occur before the Win32 audience got a hold of it. Which, in turn, should make for a great Win32 experience. I guess my point is, if these other features don't make it into 7.5 and Win32 does, that might still be a "good thing" for the potential Win32 market. Granted, if I was a developer on one of these big features and it didn't make it, I too would be fairly disappointed. Yet, once we get a release out with Win32, it should help give everyone a feel for the ability to actually support this new audience and platform. If there is a large influx of users compounded by problems, I suspect it's again, going to reflect poorly on the PostgreSQL community. ...just some ramblings.... -- Greg Copeland, Owner greg@copelandconsulting.net Copeland Computer Consulting 940.206.8004
Marc G. Fournier wrote: <blockquote cite="mid20040518113325.Q7480@ganymede.hub.org" type="cite"><pre wrap="">On Tue, 18May 2004, Robert Treat wrote: </pre><blockquote type="cite"><pre wrap="">Just like Bruce has often asked the community how they feel about him balancing his time between things like speaking engagements and patch applications, core developers have a limited amount of time they can spend on any given development effort. If I had to pick (If I got to pick?), I would rather see Bruce/Tom/Jan working on helping these guys finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5 branch. </pre></blockquote><pre wrap=""> Except you miss one key point here ... if Bruce/Tom/Jan have that sort of time, why aren't they doing it now? </pre></blockquote> Well I think you might of missed his point. His point was if he couldpick their priorities. I would kind<br /> of agree with Robert except that there are other dynamics involved... Janworks for Afilias thus does<br /> what Afilias directs him to do and what that is right now is Slony-I. <br /><br /> Tomworks for RedHat but from what I can tell is basically a rogue agent ;). However if Tom stops<br /> works what he is doingto help with PITR etc... I think a lot of the innner world of PostgreSQL would<br /> simply stop (if I am wrong pleasecorrect me). Bruce --- well what can you say about Bruce ;).<br /><br /> Seriously though, we all have the roles thatwe play. I don't think redirecting specific resources to other<br /> resources will help beyond slowing up the originalresources.<br /><br /> Sincerely,<br /><br /> Joshua D. Drake<br /><br /><br /><br /><blockquote cite="mid20040518113325.Q7480@ganymede.hub.org"type="cite"><pre wrap=""> ---- Marc G. Fournier Hub.Org Networking Services (<a class="moz-txt-link-freetext" href="http://www.hub.org">http://www.hub.org</a>) Email: <a class="moz-txt-link-abbreviated" href="mailto:scrappy@hub.org">scrappy@hub.org</a> Yahoo!: yscrappy ICQ: 7615664 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? <a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/faqs/FAQ.html">http://www.postgresql.org/docs/faqs/FAQ.html</a> </pre></blockquote><br/><br /><pre class="moz-signature" cols="72">-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a> PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>
Joshua D. Drake wrote: > >Except you miss one key point here ... if Bruce/Tom/Jan have that sort of > >time, why aren't they doing it now? > > > > > Well I think you might of missed his point. His point was if he could > pick their priorities. I would kind > of agree with Robert except that there are other dynamics involved... > Jan works for Afilias thus does > what Afilias directs him to do and what that is right now is Slony-I. > > Tom works for RedHat but from what I can tell is basically a rogue agent I like the "rogue agent". I want to be one too. :-) > ;). However if Tom stops > works what he is doing to help with PITR etc... I think a lot of the > innner world of PostgreSQL would > simply stop (if I am wrong please correct me). Bruce --- well what can > you say about Bruce ;). > > Seriously though, we all have the roles that we play. I don't think > redirecting specific resources to other > resources will help beyond slowing up the original resources. Tom is actually working on doing the fsync change for Win32 and to remove the unix dependency on sync, so in a way he is on the Win32 train right now. -- 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, Pennsylvania19073
Joshua D. Drake wrote: > >One reason against including plPHP in the core would be that it > > would create a circular build dependency between the packages > > postgresql and php. I think we should rather avoid that. > > It is no different that the dependency between plPerl and Perl, > plPython and Python or worse > plTCL and TCL (which typically isn't installed anymore). This is very much different, because the PHP distribution contains the PostgreSQL driver, whereas the other languages do not. So you would have PHP build depends on PostgreSQL PostgreSQL build depends on PHP Not good.
Marko Karppinen wrote: > I guess the key thing is that pgFoundry shouldn't be a community > distinct from the core. The same community standards need to apply > on both sides of the fence. Yes, and the best way to achieve that would be to not have anything to pgfoundry and keep everything in the core.
> > This is very much different, because the PHP distribution contains the > PostgreSQL driver, whereas the other languages do not. So you would > have > > PHP build depends on PostgreSQL Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL support to be built into PHP. Sincerely, Joshua D. Drake > PostgreSQL build depends on PHP > > Not good. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
Joshua D. Drake wrote: > > This is very much different, because the PHP distribution contains > > the PostgreSQL driver, whereas the other languages do not. So you > > would have > > > > PHP build depends on PostgreSQL > > Ahh I see your point, EXCEPT :) plPHP does not require PostgreSQL > support to be built into PHP. That is irrelevant. A normal binary package of PHP does build the PostgreSQL support (which is surely in our interest), so the build dependency holds. > > Sincerely, > > Joshua D. Drake > > > PostgreSQL build depends on PHP > > > > Not good.
> > > That is irrelevant. A normal binary package of PHP does build the > PostgreSQL support (which is surely in our interest), so the build > dependency holds. > Then I am afraid I don't understand the actual problem. plPHP does not create a circular dependency because it doesn't require PHP to have PostgreSQL support. Also PHP does not compile the PostgreSQL support by default. This is no different that Perl, which also has a PostgreSQL driver but plPerl does not require DBD::Pg to compile. Sincerely, Joshua D. Drake > >>Sincerely, >> >>Joshua D. Drake >> >> >>>PostgreSQL build depends on PHP >>> >>>Not good. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
Joshua D. Drake wrote: > Also PHP does not compile the PostgreSQL support by default. But most binary packages do, and they are the ones I'm talking about. And surely you do not advocate that, in order to build PL/PHP, the packagers instead disable the client side support in PHP?
> But most binary packages do, and they are the ones I'm talking about. > And surely you do not advocate that, in order to build PL/PHP, the > packagers instead disable the client side support in PHP? Of course not, but I still don't see your point. plPHP doesn't need PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using plPHP... PHP doesn't even need to be installed for plPHP to work... You just need the source tree for building. So I am confused... Sincerely, Joshua D. Drake
Joshua D. Drake wrote: > Of course not, but I still don't see your point. plPHP doesn't need > PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using > plPHP... > > PHP doesn't even need to be installed for plPHP to work... You just > need the source tree for building. I don't talk about manual build processes, I talk about (semi-)automatic package builds. The PHP package has a build dependency on PostgreSQL, because it needs libpq. So PostgreSQL needs to be built and installed before PHP can be built. But then, if PL/PHP were to be integrated into PostgreSQL, PHP needs to be installed first, so the PostgreSQL+PL/PHP build can get at the PHP headers files and whatever else it needs. So you can neither build PHP first nor build PostgreSQL first. So building PL/PHP doesn't need a PHP with PostgreSQL support. But no one is going to build two versions of PHP packages just so PostgreSQL can build. That is a mess we can happily avoid.
Peter Eisentraut wrote: > Joshua D. Drake wrote: > >>Of course not, but I still don't see your point. plPHP doesn't need >>PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using >>plPHP... >> >>PHP doesn't even need to be installed for plPHP to work... You just >>need the source tree for building. > O.k. now I get it.. Basically you are saying that in order to build plPHP you need PHP and PostgreSQL (regardless if they know about each other). So in order to build plPHP you need to build PostgreSQL, then PHP, then plPHP... versus just Postgresql+plPHP... However plPHP is a configure option (when patched)... Thus if they choose with-php then they would (presumably) know what they were getting into. That makes sense. Sincerely, Joshua D. Drake > > I don't talk about manual build processes, I talk about (semi-)automatic > package builds. The PHP package has a build dependency on PostgreSQL, > because it needs libpq. So PostgreSQL needs to be built and installed > before PHP can be built. But then, if PL/PHP were to be integrated > into PostgreSQL, PHP needs to be installed first, so the > PostgreSQL+PL/PHP build can get at the PHP headers files and whatever > else it needs. So you can neither build PHP first nor build PostgreSQL > first. > > So building PL/PHP doesn't need a PHP with PostgreSQL support. But no > one is going to build two versions of PHP packages just so PostgreSQL > can build. That is a mess we can happily avoid. > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > What can be done? Well, money from Fujitsu and other companies > (Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit > some of these bigger items, so hopefully that will move us forward > in these complex areas. I am not sure what could have been done to > push some of these projects along faster. Perhaps some more public cajoling of the masses into helping out would be good. Not just development but testing. Occasional posts on general asking people to help test Win32 and PITR for example, or a prominent link on the main page asking people to try out the latest Win32. It may not be "beta-ready" yet, but it surely could not hurt to have people start testing as soon as possible. I'm also sure that there is probably some more development talent available out there that could help in some of these bigger items, but I've not seen a lot of people asking for help or suggesting ways that people could help. I realize that some of this items are large and complex, but there is always /something/ that people can do, even if it documentating new features, or even documenting how to understand the new feature from a developer's perspective. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200405182046 -----BEGIN PGP SIGNATURE----- iD8DBQFAqq6GvJuQZxSWSsgRAuruAKCkzWbtYcfu9DR+f4JUHKPWjaPiswCg/Vcf ZGLywaE2OOgr3Mk+Kua1fUA= =vqHP -----END PGP SIGNATURE-----
> Seriously though, we all have the roles that we play. I don't think > redirecting specific resources to other > resources will help beyond slowing up the original resources. And now Neil's on holidays :) Perhaps we need more committers. The deluge of patches is starting to strain the major developers I think? Chris
On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote: > > But most binary packages do, and they are the ones I'm talking about. > > And surely you do not advocate that, in order to build PL/PHP, the > > packagers instead disable the client side support in PHP? > Of course not, but I still don't see your point. plPHP doesn't need > PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using > plPHP... > PHP doesn't even need to be installed for plPHP to work... You just > need the source tree for building. So you then have to build PHP twice, in an RPM build environment. You mean I can't just have the headers installed to build plPHP? So, follow the sequence of the RPM building events: 1.) Build PHP without PostgreSQL client support. 2.) Build PostgreSQL 3.) Build plPHP 4.) Build PHP with PostgreSQL client support. The Perl situation is totally different, since the Perl client is not part of the Perl source tree. The 4-step I mention above would never be followed by any distributions, who would probably just not build plPHP to keep from having the circular dependency. See, in the RPM build environment for self-hosting distributions, I would have to pull in the entire PHP source distribution during the PostgreSQL build. Keeping that synchronized with the PHP version that is the main one distributed would be a major pain. Better would be getting plPHP so that it doesn't need the PostgreSQL source tree, but just needs the development headers (with server-side) installed. Then there is no circular build dependency. Then I just: 1.) Build PostgreSQL 2.) Build PHP (with PostgreSQL client support) 3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client support for cross database queries? :-)) Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you solved the circular dependency. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
> So you then have to build PHP twice, in an RPM build environment. You mean I > can't just have the headers installed to build plPHP? So, follow the No you need to make sure that PHP is available as a shared lib. > 1.) Build PostgreSQL > 2.) Build PHP (with PostgreSQL client support) > 3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client > support for cross database queries? :-)) Right. > > Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you > solved the circular dependency. Actually plPHP doesn't require the PostgreSQL source tree... you would just have to modify the Make file to point to the right places. J
On Tuesday 18 May 2004 21:58, Joshua D. Drake wrote: > > So you then have to build PHP twice, in an RPM build environment. You > > mean I can't just have the headers installed to build plPHP? So, follow > > the > No you need to make sure that PHP is available as a shared lib. Which requires you to build PHP. PHP is only going to get built once; do you build with or without PostgreSQL client support? As an RPM builder, you cannot build it one way, then rebuild it again another way. It's not self-hosting at that point. > > Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how > > you solved the circular dependency. > Actually plPHP doesn't require the PostgreSQL source tree... you would > just have to modify the Make file to point to the right places. Then it can easily be a standalone project, and the issues go away. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
On Tue, 18 May 2004, Joshua D. Drake wrote: > Actually plPHP doesn't require the PostgreSQL source tree... you would > just have to modify the Make file to point to the right places. So, why tie it into the PostgreSQL source tree? Won't it be popular enough to live on its own, that it has to be distributed as part of the core? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> On Tue, 18 May 2004, Joshua D. Drake wrote: > > > Actually plPHP doesn't require the PostgreSQL source tree... you would > > just have to modify the Make file to point to the right places. > > So, why tie it into the PostgreSQL source tree? Won't it be popular > enough to live on its own, that it has to be distributed as part of the > core? At least in Japan PHP is much more popular than Python. If we have plpython in core, I see no reason we do not have plPHP in core at least from the "popularity" point of view. -- Tatsuo Ishii
>So, why tie it into the PostgreSQL source tree? Won't it be popular >enough to live on its own, that it has to be distributed as part of the >core? > > > Honestly, I don't know if it would be popular enough on its own. Now the plPerlNG that Andrew and us are working, yes but plPHP? It is nifty, it is cool, it is very capable but it is still PHP. I think the point of having it in core is that the three most popular user space languages are: Python Perl PHP If those are covered within core under the pl* then we have all bases covered. I am not saying that it should be in core (although I definately think plPerlNG should be). This all started because it was suggested it could be :) J >---- >Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Tatsuo Ishii wrote:<br /><blockquote cite="mid20040519.130456.112624363.t-ishii@sra.co.jp" type="cite"><pre wrap="">
At least in Japan PHP is much more popular than Python. If we have
plpython in core, I see no reason we do not have plPHP in core at
least from the "popularity" point of view. </pre></blockquote><br /> Well I don't know anywhere that PHP isn't more
popularthan Python. The question I think<br /> is a technical one. Python is a better "language" that PHP is. Perl is
aswell but that is a whole<br /> other argument.<br /><br /> PHP is what I call the "Dumb Monkey" language. It isn't
meantto be rude, but the reality is<br /> that almost any dumb monkey can code something in PHP. Python takes actual
thoughtto<br /> produce something useful.<br /><br /> Whether or not that is a bad thing is for another argument :)<br
/><br/> Sincerely,<br /><br /> Joshua D. Drake<br /><br /><br /><br /><blockquote
cite="mid20040519.130456.112624363.t-ishii@sra.co.jp"type="cite"><pre wrap="">--
Tatsuo Ishii
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
<a class="moz-txt-link-freetext" href="http://archives.postgresql.org">http://archives.postgresql.org</a>
</pre></blockquote><br/><br /><pre class="moz-signature" cols="72">--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a
class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a>
PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>
Greg Sabino Mullane wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>What can be done? Well, money from Fujitsu and other companies >>(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit >>some of these bigger items, so hopefully that will move us forward >>in these complex areas. I am not sure what could have been done to >>push some of these projects along faster. > > > Perhaps some more public cajoling of the masses into helping out > would be good. Not just development but testing. Occasional posts on > general asking people to help test Win32 and PITR for example, or a > prominent link on the main page asking people to try out the latest > Win32. It may not be "beta-ready" yet, but it surely could not hurt > to have people start testing as soon as possible. I'm one of those that should probably be testing early. As it stands, I'm subscribed to -hackers and if I downloaded a snapshot from today I still don't know what it is I'd be testing. How about a series of mini-releases (say) every 8 weeks - 7 weeks patching, 1 week stabilising. That would provide something solid enough to do some development work with, but you're not going to cry if (e.g.) nested transactions didn't work with system tables. Is that a plausible situation, or madness from a developer-resources point of view? -- Richard Huxton Archonet Ltd
Richard Huxton wrote: > >>What can be done? Well, money from Fujitsu and other companies > >>(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit > >>some of these bigger items, so hopefully that will move us forward > >>in these complex areas. I am not sure what could have been done to > >>push some of these projects along faster. > > > > > > Perhaps some more public cajoling of the masses into helping out > > would be good. Not just development but testing. Occasional posts on > > general asking people to help test Win32 and PITR for example, or a > > prominent link on the main page asking people to try out the latest > > Win32. It may not be "beta-ready" yet, but it surely could not hurt > > to have people start testing as soon as possible. > > I'm one of those that should probably be testing early. As it stands, > I'm subscribed to -hackers and if I downloaded a snapshot from today I > still don't know what it is I'd be testing. > > How about a series of mini-releases (say) every 8 weeks - 7 weeks > patching, 1 week stabilising. That would provide something solid enough > to do some development work with, but you're not going to cry if (e.g.) > nested transactions didn't work with system tables. > > Is that a plausible situation, or madness from a developer-resources > point of view? We actually don't need more testing. We already know the missing issues with most features. The big problem is finding folks who have the time to ramp up the steep learning curve needed to contribute to these complex 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, Pennsylvania19073
Richard Huxton <dev@archonet.com> writes:
> I'm one of those that should probably be testing early. As it stands,
> I'm subscribed to -hackers and if I downloaded a snapshot from today I
> still don't know what it is I'd be testing.
> How about a series of mini-releases (say) every 8 weeks - 7 weeks
> patching, 1 week stabilising.
I think that would be fairly useless. CVS tip is rarely broken to the
extent of not being worthy of testing --- we simply won't apply patches
that break it, because they'd interfere with other development work.
The main downside of testing a snapshot, as I see it, is that the
snapshot is virtually certain not to be initdb-compatible with either
the previous release or the upcoming one. Mini-releases would have
that problem too, and so I don't really see what they add in terms of
testability.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Marc G. Fournier wrote:
>> That is the plan ... unless someone knows a reason why they can't be
>> built independently of the core?
> How about this one: Everything we have moved from the core to gborg so
> far has been a miserable failure.
JDBC seems to be doing fine ... but I think that exception just proves
your point. If there's not a viable community around a particular piece
of code, pushing it out to gborg/pgFoundry won't magically create one.
I strongly disagree with moving out the existing PLs; it's just a whole
lot easier to maintain them alongside the backend. (This is especially
true of plpgsql of course, but it is very common that global edits hit
the other PLs as well.) I think Joe Conway's experience with
maintaining plR separately shows the overhead involved.
I would like to see plperlNG eventually supplant the existing plperl in
core CVS. If it weren't for the circular-build-dependency issue, I'd
probably be in favor of pulling in plPHP too.
I do see a point to having pgFoundry though, which is that it allows
more people to be granted direct commit access to the bits of code they
are working on. For the core project, I think we should continue the
present policy of keeping commit access pretty closely held, so pulling
all that stuff back in would make the committers a real bottleneck.
With separate projects we can let each project determine its own commit
access policies.
I agree with the opinion that we need to figure out how to produce
more-or-less-integrated release filesets from multiple projects.
There's too much stuff being pushed out for development or release
engineering reasons that users want to see as part of the standard
product. We've let the lure of "separate projects can have separate
release schedules" blind us to the fact that for most projects there's
not really any benefit there. Client-side libraries like JDBC can
get some benefit, but server-side stuff I don't think so.
regards, tom lane
On Wed, May 19, 2004 at 09:20:57AM +0800, Christopher Kings-Lynne wrote: > >Seriously though, we all have the roles that we play. I don't think > >redirecting specific resources to other > >resources will help beyond slowing up the original resources. > > And now Neil's on holidays :) Not yet I hope. I'm still counting on the list rewrite being done. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "Limítate a mirar... y algun día veras"
Tom Lane wrote: >Peter Eisentraut <peter_e@gmx.net> writes: > > >>Marc G. Fournier wrote: >> >> >>>That is the plan ... unless someone knows a reason why they can't be >>>built independently of the core? >>> >>> > > > >>How about this one: Everything we have moved from the core to gborg so >>far has been a miserable failure. >> >> > >JDBC seems to be doing fine ... but I think that exception just proves >your point. If there's not a viable community around a particular piece >of code, pushing it out to gborg/pgFoundry won't magically create one. > >I strongly disagree with moving out the existing PLs; it's just a whole >lot easier to maintain them alongside the backend. (This is especially >true of plpgsql of course, but it is very common that global edits hit >the other PLs as well.) I think Joe Conway's experience with >maintaining plR separately shows the overhead involved. > >I would like to see plperlNG eventually supplant the existing plperl in >core CVS. If it weren't for the circular-build-dependency issue, I'd >probably be in favor of pulling in plPHP too. > > Amen. plperlNG was always intended as a replacement. In fact, one of the reasons I'm a bit sad about us rushing to feature freeze on 1 June is that Joshua and I had hoped to get a greatly beefed up plperl ready in time for 7.5, but I don't think we can make June 1. >I do see a point to having pgFoundry though, which is that it allows >more people to be granted direct commit access to the bits of code they >are working on. > Indeed. One of the great uses of pgfoundry is as a community site that can be used for things intended for eventual inclusion in the core but not yet ready for it. >For the core project, I think we should continue the >present policy of keeping commit access pretty closely held, so pulling >all that stuff back in would make the committers a real bottleneck. >With separate projects we can let each project determine its own commit >access policies. > > It's a timing thing. When plperlng is ready we will present a largish patch or set of patches. At that time the separate project would shut down and plperl would once again be maintained as part of the core. cheers andrew
> Amen. plperlNG was always intended as a replacement. > > In fact, one of the reasons I'm a bit sad about us rushing to feature > freeze on 1 June is that Joshua and I had hoped to get a greatly beefed > up plperl ready in time for 7.5, but I don't think we can make June 1. I don't think we will make it either. June 15th maybe. Sincerely, Joshua D. Drake
Greg Copeland wrote: > On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote: > >>On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote: >> >> >>>fact that checkpoints, vacuum runs and pg_dumps bog down their machines >>>to the state where simple queries take several seconds care that much >>>for any Win32 port? Do you think it is a good sign for those who have >> >>Yes. I am one such person, but from the marketing side of things, I >>understand perfectly well what failing to deliver on Win32 again will >>cost. It's not important to _me_, but that doesn't mean it's >>unimportant to the project. >> > > > My primary fear about delivering Win32 with all of these other great > features is that, IMO, there is a higher level of risk associated with > these advanced features. At the same time, this will be the first trial > for many Win32 users. Should there be some problems, in general, or > worse, specific to Win32 users as it relates to these new features, it > could cost some serious Win32/PostgreSQL community points. A troubled > release which is experienced by Win32 users is going to be a battle cry > for MySQL. I believe that the very first Win32 native version will be declared "not realy ready for production", am I wrong ? Regards Gaetano Mendola
On Thu, 2004-05-20 at 19:59, Gaetano Mendola wrote:
> Greg Copeland wrote:
>
> > On Tue, 2004-05-18 at 09:30, Andrew Sullivan wrote:
> >
> >>On Sun, May 16, 2004 at 02:46:38PM -0400, Jan Wieck wrote:
> >>
> >>
> >>>fact that checkpoints, vacuum runs and pg_dumps bog down their machines
> >>>to the state where simple queries take several seconds care that much
> >>>for any Win32 port? Do you think it is a good sign for those who have
> >>
> >>Yes. I am one such person, but from the marketing side of things, I
> >>understand perfectly well what failing to deliver on Win32 again will
> >>cost. It's not important to _me_, but that doesn't mean it's
> >>unimportant to the project.
> >>
> >
> >
> > My primary fear about delivering Win32 with all of these other great
> > features is that, IMO, there is a higher level of risk associated with
> > these advanced features. At the same time, this will be the first trial
> > for many Win32 users. Should there be some problems, in general, or
> > worse, specific to Win32 users as it relates to these new features, it
> > could cost some serious Win32/PostgreSQL community points. A troubled
> > release which is experienced by Win32 users is going to be a battle cry
> > for MySQL.
>
> I believe that the very first Win32 native version will be declared "not
> realy ready for production", am I wrong ?
>
Given that the cygwin version is currently labeled as not ready for
production I would say you are right. The truth is that many will never
declare win32 good for production simply because of the OS it runs on,
but we still want to make it as solid as possible.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > Given that the cygwin version is currently labeled as not ready for > production I would say you are right. The truth is that many will never > declare win32 good for production simply because of the OS it runs on, > but we still want to make it as solid as possible. People _do_ use postgresql+cygwin in production environments though (see the pgsql-cygwin archive). And I suspect people _will_ use 7.5 for win32 in production, despite the release notes and the website clearly saying it's not production ready. Why? 1) The version number is "7.5" and many people will presume the ports are more or less equal in quality/maturity since they have the same version number; 2) People don't read release notes. See the various reviews on the recently released Fedora Core 2, complaining about how it doesn't support MP3 or DVD playback, despite the [legal] issues having been known and documented since Red Hat 8. Strangely enough, these people (who don't read release notes) _do_ write public reviews. They will badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being much much more rock solid, etc etc. I suggest we label the win32 port as "7.5 ALPHA" or "7.5 DANGEROUS" :-) -- dave
David Garamond wrote: > Robert Treat wrote: > >> Given that the cygwin version is currently labeled as not ready for >> production I would say you are right. The truth is that many will never >> declare win32 good for production simply because of the OS it runs on, >> but we still want to make it as solid as possible. > > > People _do_ use postgresql+cygwin in production environments though (see > the pgsql-cygwin archive). > > And I suspect people _will_ use 7.5 for win32 in production, despite the > release notes and the website clearly saying it's not production ready. > Why? > > 1) The version number is "7.5" and many people will presume the ports > are more or less equal in quality/maturity since they have the same > version number; > > 2) People don't read release notes. See the various reviews on the > recently released Fedora Core 2, complaining about how it doesn't > support MP3 or DVD playback, despite the [legal] issues having been > known and documented since Red Hat 8. Strangely enough, these people > (who don't read release notes) _do_ write public reviews. They will > badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being > much much more rock solid, etc etc. > > I suggest we label the win32 port as "7.5 ALPHA" or "7.5 DANGEROUS" :-) My concern is about the fact the fact that Postgresql rely on the OS about his ability to optimize memory access. Do we have any possibility at this stage to compare Postgresql performance on top of Win32 with other products for this platform ? I think that Postgresql with this version is going to address a specific class of final users that right now are using what ? I don't think the response is: "users that now are using postgresql+cygwin". Can the first version of postgresql for Win32 compared with other products? I really hope yes, you know: there is no a *second* possibility to do a *first* good impression. Regards Gaetano Mendola
We could perhaps do something similar to the Apache 1.3 win platform
notes, where they (still) say *something* like :
"Apache on windows is not as stable as on unix... but is being actively
improved all the time"
This is a bit more positive than "it's dangerous!".
As for people not reading the release notes - we could display the
platform note (or an href to it) prominently on the download page
("they" may still not read that...but it has become a matter of choice
at that point...).
regards
Mark
David Garamond wrote:
> Robert Treat wrote:
>
>> Given that the cygwin version is currently labeled as not ready for
>> production I would say you are right. The truth is that many will never
>> declare win32 good for production simply because of the OS it runs on,
>> but we still want to make it as solid as possible.
>
>
> People _do_ use postgresql+cygwin in production environments though
> (see the pgsql-cygwin archive).
>
> And I suspect people _will_ use 7.5 for win32 in production, despite
> the release notes and the website clearly saying it's not production
> ready. Why?
>
> 1) The version number is "7.5" and many people will presume the ports
> are more or less equal in quality/maturity since they have the same
> version number;
>
> 2) People don't read release notes. See the various reviews on the
> recently released Fedora Core 2, complaining about how it doesn't
> support MP3 or DVD playback, despite the [legal] issues having been
> known and documented since Red Hat 8. Strangely enough, these people
> (who don't read release notes) _do_ write public reviews. They will
> badmouth PostgreSQL, saying it's unstable, crashes a lot, MySQL being
> much much more rock solid, etc etc.
>
> I suggest we label the win32 port as "7.5 ALPHA" or "7.5 DANGEROUS" :-)
>
On Sat, 2004-05-22 at 23:44, Mark Kirkwood wrote:
> We could perhaps do something similar to the Apache 1.3 win platform
> notes, where they (still) say *something* like :
>
> "Apache on windows is not as stable as on unix... but is being actively
> improved all the time"
>
> This is a bit more positive than "it's dangerous!".
Yes it's more positive, but I think there is more danger associated with
an untested database enviornment than an untested web server. Apache
might crash, but it probably won't eat your data.
> As for people not reading the release notes - we could display the
> platform note (or an href to it) prominently on the download page
> ("they" may still not read that...but it has become a matter of choice
> at that point...).
There will always be people who won't read the notes, or ignore the
notes, as there will always be people doing all sorts of stupid things
that we can't protect them from. There is only so much we can and
should do to protect these types of people. I think if we just make
sure we warn people in several places so that anyone who does read the
release notes will find it.
Matthew
"Matthew T. O'Connor" <matthew@zeut.net> writes:
> There will always be people who won't read the notes, or ignore the
> notes,
Does anyone want to contemplate hacking things so that the Windows port
reports a different version number? "0.1" might give people the right
sort of impression about what we think of that port's stability ...
regards, tom lane
On Sun, 23 May 2004, Tom Lane wrote: > "Matthew T. O'Connor" <matthew@zeut.net> writes: > > There will always be people who won't read the notes, or ignore the > > notes, > > Does anyone want to contemplate hacking things so that the Windows port > reports a different version number? "0.1" might give people the right > sort of impression about what we think of that port's stability ... How about a pop-up when starting up that repeatedly reinforces that this is considered a early port, and should be treated as such in a production environment. When we have it to the point we consider stable, we remove teh popup? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
The "warn 'em in several places" seems like a very good approach. regards Mark Matthew T. O'Connor wrote: > >There will always be people who won't read the notes, or ignore the >notes, as there will always be people doing all sorts of stupid things >that we can't protect them from. There is only so much we can and >should do to protect these types of people. I think if we just make >sure we warn people in several places so that anyone who does read the >release notes will find it. > > >
Bruce, on May 17, 2004, you wrote: > So, yea, I am frustrated. I know these features are hard and complex, > but I want them for PostgreSQL, and I want them as soon as possible. I > guess what really bugs me is that we are so close to having these few > remaining big features, and because they are so complex, they are taking > a lot longer to arrive than previous features, and sometimes see a year > pass without progress on some items, and that bugs me. This discussion was taking place as we closed the 7.5 development cycle, and we weren't getting PITR, tablespaces, nested transactions, 2PC, the Win32 port, in the release. We have all those things now. We have gone a long way now, even though it was only a year ago. My question for everyone on this list is: What are the "few remaining big features" that you see missing for PostgreSQL? Or, slightly different, what are people's most wanted features? Has PostgreSQL started slowing down in getting new features, and concentrating mostly on performance issues? -- Alvaro Herrera (<alvherre[a]alvh.no-ip.org>) A male gynecologist is like an auto mechanic who never owned a car. (Carrie Snow)
> We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? Table partitioning is pretty big but I believe we have that already for 8.2 per Greenplum. Better aggregate performance Real materialized views Anything that goes zoom, zoom, zoom of course! Not to mention the WHOLE todo list :) Sincerely, Joshua D. Drake > > Or, slightly different, what are people's most wanted features? > > Has PostgreSQL started slowing down in getting new features, and > concentrating mostly on performance issues? > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Thu, 25 Aug 2005, Alvaro Herrera wrote: > Bruce, on May 17, 2004, you wrote: > > > So, yea, I am frustrated. I know these features are hard and complex, > > but I want them for PostgreSQL, and I want them as soon as possible. I > > guess what really bugs me is that we are so close to having these few > > remaining big features, and because they are so complex, they are taking > > a lot longer to arrive than previous features, and sometimes see a year > > pass without progress on some items, and that bugs me. > > This discussion was taking place as we closed the 7.5 development cycle, > and we weren't getting PITR, tablespaces, nested transactions, 2PC, the > Win32 port, in the release. We have all those things now. > > We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? > > Or, slightly different, what are people's most wanted features? SQL: Grouping sets Recursive queries Window functions Updatable views Updatable cursors Materialised views Debug-able PL/PgSQL -- EXPLAIN [ANALYZE] functionality, step through? Cost estimation for functions -- perhaps a pipe dream, I know Performance: Better bulk load 'Continuous' vacuum at a fraction of the IO cost of normal vacuum Multimaster replication General OLTP throughput improvements -- where and how, I'm not sure. Indexes: Bitmap indexes (as opposed to bitmap scans) --- There are other things which would be cool to see, but these are high on the list. Thanks, Gavin
On 8/25/05 4:13 PM, "Alvaro Herrera" <alvherre@alvh.no-ip.org> wrote: > We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? > > Or, slightly different, what are people's most wanted features? Table partitioning would be huge, but it looks like that is on its way. Index-organized tables are the most significant thing at the top of my wish list, as that would generate a huge performance increase for much of what I spend my time on with PostgreSQL. There is currently no good way to approximate it. J. Andrew Rogers jrogers@neopolitan.com
Alvaro, > We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? -- on-disk bitmaps and composite indexes (due out for Bizgres in about a month) -- More table partitioning stuff -- materialized view support -- streams (per TelegraphCQ) -- database ASSERTIONS -- clustering (SlonyII) -- multi-threaded/process query execution (i.e. one query, multiple processors) -- more robust message queing -- SQL99 TYPES (aka Packages) -- Recursive Joins -- MERGE -- interactive/automated database performance tuning -- index-only access -- automated creation of updatable views > Has PostgreSQL started slowing down in getting new features, and > concentrating mostly on performance issues? Hmmm, I don't think so. We will eventually, but there's still plenty of features left. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Gavin Sherry wrote: >> >>Or, slightly different, what are people's most wanted features? >> >> > >SQL: > >Grouping sets >Recursive queries >Window functions >Updatable views >Updatable cursors >Materialised views >Debug-able PL/PgSQL -- EXPLAIN [ANALYZE] functionality, step through? >Cost estimation for functions -- perhaps a pipe dream, I know > > > > and Merge (which I know Gavin also wants). cheers andrew
Alvaro, > -- on-disk bitmaps and composite indexes (due out for Bizgres in about a > month) > -- More table partitioning stuff > -- materialized view support > -- streams (per TelegraphCQ) > -- database ASSERTIONS > -- clustering (SlonyII) > -- multi-threaded/process query execution (i.e. one query, multiple > processors) > -- more robust message queing > -- SQL99 TYPES (aka Packages) > -- Recursive Joins > -- MERGE > -- interactive/automated database performance tuning > -- index-only access > -- automated creation of updatable views Oh, yeah I forgot: -- windowing functions (e.g. RANK, RANK OVER, LAST 10) -- --Josh Josh Berkus Aglio Database Solutions San Francisco
On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote: > Bruce, on May 17, 2004, you wrote: > > > So, yea, I am frustrated. I know these features are hard and complex, > > but I want them for PostgreSQL, and I want them as soon as possible. I > > guess what really bugs me is that we are so close to having these few > > remaining big features, and because they are so complex, they are taking > > a lot longer to arrive than previous features, and sometimes see a year > > pass without progress on some items, and that bugs me. > > This discussion was taking place as we closed the 7.5 development cycle, > and we weren't getting PITR, tablespaces, nested transactions, 2PC, the > Win32 port, in the release. We have all those things now. > > We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? > > Or, slightly different, what are people's most wanted features? I have an immediate use for: * Identity/generator support (per standard) * Merge (update/insert as required) * Multi-CPU sorts. Take a large single sort like an index creation and split the work among multiple CPUs. --
Rod Taylor wrote: > * Multi-CPU sorts. Take a large single sort like an index creation > and split the work among multiple CPUs. > > > This really implies threading, doesn't it? And presumably it would have many possible uses besides this one for doing parallel work, e.g. maybe the planner could evaluate several alternative plans in parallel. cheers andrew
On Thu, 2005-08-25 at 21:27 -0400, Andrew Dunstan wrote: > > Rod Taylor wrote: > > > * Multi-CPU sorts. Take a large single sort like an index creation > > and split the work among multiple CPUs. > This really implies threading, doesn't it? And presumably it would have > many possible uses besides this one for doing parallel work, e.g. maybe > the planner could evaluate several alternative plans in parallel. I don't think threading is needed. I pictured PostgreSQL spawning one process per CPU explicitly for sorting which standard backends could use as required to do batch work. Not necessarily easy to do but it would sure be handy. --
> We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? > > Or, slightly different, what are people's most wanted features? * Recursive unions (ie. WITH recursive) * CUBE & ROLLUP * The rest of the oracle analytic functions (http://www.akadia.com/services/ora_analytic_functions.html) I'm happy with new features and performance, but I'd really like to be able to do complex analysis of the huge statistics tables I have :) Chris
> We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? > > Or, slightly different, what are people's most wanted features? Oh, and MERGE :D Chris
Rod Taylor wrote: >On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote: > > >>Bruce, on May 17, 2004, you wrote: >> >> >> >>>So, yea, I am frustrated. I know these features are hard and complex, >>>but I want them for PostgreSQL, and I want them as soon as possible. I >>>guess what really bugs me is that we are so close to having these few >>>remaining big features, and because they are so complex, they are taking >>>a lot longer to arrive than previous features, and sometimes see a year >>>pass without progress on some items, and that bugs me. >>> >>> >>This discussion was taking place as we closed the 7.5 development cycle, >>and we weren't getting PITR, tablespaces, nested transactions, 2PC, the >>Win32 port, in the release. We have all those things now. >> >>We have gone a long way now, even though it was only a year ago. My >>question for everyone on this list is: What are the "few remaining big >>features" that you see missing for PostgreSQL? >> >>Or, slightly different, what are people's most wanted features? >> >> > >I have an immediate use for: > * Identity/generator support (per standard) > * Merge (update/insert as required) > * Multi-CPU sorts. Take a large single sort like an index creation > and split the work among multiple CPUs. > > > I am just a novice end user, but I would like to see: SavePoints be able to use within functions. ( I think this involves making procedures that execute outside of a transaction) Cross Database references. (Available through dblink, but itwould be better if it was supported natively) The ability to say create function foo () returns setof record(int, int , int). I believe this is coming in the next release though.
Rod Taylor wrote: > On Thu, 2005-08-25 at 21:27 -0400, Andrew Dunstan wrote: > >>Rod Taylor wrote: >> >> >>> * Multi-CPU sorts. Take a large single sort like an index creation >>> and split the work among multiple CPUs. > >>This really implies threading, doesn't it? And presumably it would have >>many possible uses besides this one for doing parallel work, e.g. maybe >>the planner could evaluate several alternative plans in parallel. > > I don't think threading is needed. > > I pictured PostgreSQL spawning one process per CPU explicitly for > sorting which standard backends could use as required to do batch work. This is one area where PostgreSQL needs a lot of work to catch up to the competition. Oracle, DB2, Ingres, even SQL ServerEnterprise edition all have parallel query capabilities. I have an older 8-processor Sun Enterprise 3500, as an example. It still has use with other vendors' database products due to their parallel feature set (make -j 9 is nice too), but behaves like the boat-anchor it is w.r.t. PostgreSQL. Mike Mascari
Nicholas, You are a novice user, aren't you? ;-) > I am just a novice end user, but I would like to see: > SavePoints be able to use within functions. ( I think this involves > making procedures that execute outside of a transaction) Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages. > Cross Database references. (Available through dblink, but it would > be better if it was supported natively) You'll have to argue this one. We don't have them on purpose. Generally when people want "cross-database queries" the problem is that they really should be using schema. > The ability to say create function foo () returns setof record(int, > int , int). I believe this is coming in the next release though. Well, we've had this for 3 versions as CREATE TYPE ... CREATE FUNCTION. INOUT parameters in 8.1 will give you the above, effectively. -- Josh Berkus Aglio Database Solutions San Francisco
On Thu, 25 Aug 2005, Josh Berkus wrote: > > SavePoints be able to use within functions. ( I think this involves > > making procedures that execute outside of a transaction) > > Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages. You can't use savepoints, you can trap errors which is implemented using savepoints. You still might want to write code like this: BEGIN .... SAVEPOINT foo; .... IF SOME_ERROR_CODE = 1234 THEN ROLLBACK TO SAVEPOINT foo; END ... You can write code like this if you issue each command from the client, say using libpq, but not in pl/pgsql. -- /Dennis Björklund
On N, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote: > We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining big > features" that you see missing for PostgreSQL? > > Or, slightly different, what are people's most wanted features? my pet wishes are : 24/7 OLTP related things * vacuums that ignore other vacuums when deciding what tuples to free (should be mostly done, my patch wasleft to 8.2 due to some doubts by Tom) * non-blocking CREATE INDEX / REINDEX (so indexes can be added to huge tables on busy databases without downtime) * related to last one - command to promote UNIQUE INDEX to PRIMARY KEY. * multiple WAL's, assignable to objects (similaŕ to tablespaces). * better 64-bit support inside db engine. * real background vacuuming, using something like FSM, may be integrated with background writer. * VACUUM FULL/CLUSTER added behaviour of leaving pages half-empty (or any.other-percentage-empty) for good update behaviour. OLAP stuff * table partitioning to move forward. * archive tables (append (==insert) only, only one writer at a time, vacuum needed after rollbacked insert, visibility determined by "last valid ctid" marker, so will not need most of header fields either). * index-only scans over archive tables (possible without altering current index structure, as visibility can be determined by ctid which is already present in index leaf). > Has PostgreSQL started slowing down in getting new features, and > concentrating mostly on performance issues? I can't think of this as new features vs. performance thing as many of the new features *are* largely about performance, both on database engine and on user side. -- Hannu Krosing <hannu@skype.net>
On Thu, Aug 25, 2005 at 07:13:18PM -0400, Alvaro Herrera wrote: > Bruce, on May 17, 2004, you wrote: > > > So, yea, I am frustrated. I know these features are hard and > > complex, but I want them for PostgreSQL, and I want them as soon > > as possible. I guess what really bugs me is that we are so close > > to having these few remaining big features, and because they are > > so complex, they are taking a lot longer to arrive than previous > > features, and sometimes see a year pass without progress on some > > items, and that bugs me. > > This discussion was taking place as we closed the 7.5 development > cycle, and we weren't getting PITR, tablespaces, nested > transactions, 2PC, the Win32 port, in the release. We have all > those things now. > > We have gone a long way now, even though it was only a year ago. My > question for everyone on this list is: What are the "few remaining > big features" that you see missing for PostgreSQL? > > Or, slightly different, what are people's most wanted features? > > Has PostgreSQL started slowing down in getting new features, and > concentrating mostly on performance issues? Along with all the other cool stuff people have already mentioned, I'd like to see composite types handled better--they're not quite first-class objects yet. Also nice to have: * optional interface which sends a row typeoid along with each row in a result set * more visibility from RULEs into the expression tree generated by the parser and/or other RULEs * SQL/MED (or at least things that would make it easier to implement) * Debugging hooks into all the PLs * Some way of estimating a "query progress meter" for long-running queries * MULTISET, COLLECT, UNNEST, FUSION, INTERSECT oh, and MERGE! MERGE! MERGE! MERGE! MERGE! MERGE! Cheers, D -- David Fetter david@fetter.org http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote!
* Alvaro Herrera (alvherre@alvh.no-ip.org) wrote: > Or, slightly different, what are people's most wanted features? MERGE. Stephen
Dennis Bjorklund wrote: >On Thu, 25 Aug 2005, Josh Berkus wrote: > > > >>> SavePoints be able to use within functions. ( I think this involves >>>making procedures that execute outside of a transaction) >>> >>> >>Nope, supported in 8.0 for PL/pgSQL. Not sure about other languages. >> >> > >You can't use savepoints, you can trap errors which is implemented using >savepoints. You still might want to write code like this: > >BEGIN > >.... > >SAVEPOINT foo; > >.... > >IF SOME_ERROR_CODE = 1234 THEN > ROLLBACK TO SAVEPOINT foo; >END > >... > > >You can write code like this if you issue each command from the client, >say using libpq, but not in pl/pgsql. > > > I agree, and I think savepoints would be much more usefull if you could call them from pl/pgsql...
On Fri, 2005-08-26 at 13:13 -0400, Nicholas Walker wrote: > >You can't use savepoints, you can trap errors which is implemented using > >savepoints. You still might want to write code like this: > > > >BEGIN > > > >.... > > > >SAVEPOINT foo; > > > >.... > > > >IF SOME_ERROR_CODE = 1234 THEN > > ROLLBACK TO SAVEPOINT foo; > >END > > > >... > I agree, and I think savepoints would be much more usefull if you could > call them from pl/pgsql... Maybe if PL/pgSQL had user-defined exceptions then the language's identity of savepoints and exception blocks would be a little easier to work with. Is anything happening with the patch for user-defined exceptions, posted at http://archives.postgresql.org/pgsql-patches/2005-06/msg00475.php (and also discussed elsewhere)?
On Thu, 25 Aug 2005, Alvaro Herrera wrote: > Or, slightly different, what are people's most wanted features? Since you asked: * concurrent, partial vacuum that would for example only scan pages that happen to be in memory * index-only scans * database assertions * lightwight PITR that wouldn't require to shut down and restore a backup. I'm thinking something like "REWIND TO xid 12345". It could be implemented by just setting already-committed transactions as aborted in the clog (vacuum and commit status hint bits need to be disabled beforehand). This would be very handy for automatic regression testing applications. You could load the test database just once, then run test case, rewind, run another test case, rewind and so on. As more disruptive longer-term things: * multiple alternative access plans for prepared statements. For example, if you have a query like "SELECT * FROM history WHERE timestamp BETWEEN ? AND ?", the optimal access plan depends a lot on the parameters. Postgres could keep all the plans that are optimal for some combination of parameters, and choose the most efficient one at execution time depending on the parameters. The execution side would actually be quite simple to implement. Introduce a new conditional node type that has > 1 child nodes, and a condition that is evaluated at execution time and determines which child node to use. Determining the conditions would require big changes to the planner and estimation routines. * support for Tutorial D as an alternative to SQL. It would be great for educational purposes. - Heikki
Alvaro Herrera wrote: > Or, slightly different, what are people's most wanted features? Things I would have found useful in the past year or so include: Standards stuff: * Updateable views (easier to use Ruby/Rails's ActiveRecord on legacy data) * The elementary OLAP stuff Contrib related stuff: * Contrib/xml2 working with XML Namespaces. * Some sort of GIST index for querying XML data (XPath? SQL/XML?) * The array functions and indexes from contrib/intarray and contrib/intagg made more general to work with other datatypes. (I find these contrib modules quite useful) Annoyances: * more sane math with intervals. For example, try: select '0.01 years'::interval, '0.01 months'::interval; Ease of use: * Nice defaults for autovacuum and checkpoints and bgwriter that automatically avoid big I/O spikes by magically distributingI/O in a nice way. Easier COPY for client library authors: * A way to efficiently insert many values like COPY from STDIN from client libraries that don't support COPY from STDIN. Perhaps it could happen through the apparently standards compliant "INSERT INTO table VALUES (1,2),(3,4),(5,6)" [feature id F641] or perhaps through a new COPY tablename FROM STRING 'a big string instead of stdin' feature that would be easier for clients to support? It seems in most new client libraries COPY FROM STDIN stays broken for quite a long time. Would a alternative COPYFROM A_BIG_STRING be easier for them to support and therefore available more often? Meta-stuff * A failover plus load-balancing (pgpool+slony?) installer for dummies that handles simple cases. * A single place to find all the useful non-core stuff like projects on pgfoundry, gborg, contrib, and various otherplaces around the net (PL/R PL/Ruby Postgis). Perhaps if the postgresql website had a small wiki somewhere whereanyone could add links with a short description to any such projects it'd be easier to know what's out there... * Nice APIs and documentation [probably already exists] to continue encouraging projects like PostGIS and PL/R thatIMHO are the biggest advantage of postgresql over the commercial vendors' offerings. Oh, and seeing everyone else's response, I suppose I should add MERGE though I haven't actually noticed a need yet. :-)
Hi all, Our organizations are doing a lot of real time reporting involving queries with multiple tables, and large tables. I found that two features are very nice to have: - Table Partition - Materialized view Thanks, J On 8/26/05, Ron Mayer <rm_pg@cheapcomplexdevices.com> wrote: > Alvaro Herrera wrote: > > > Or, slightly different, what are people's most wanted features? > > Things I would have found useful in the past year or so include: > > Standards stuff: > > * Updateable views (easier to use Ruby/Rails's ActiveRecord on legacy data) > * The elementary OLAP stuff > > Contrib related stuff: > > * Contrib/xml2 working with XML Namespaces. > * Some sort of GIST index for querying XML data (XPath? SQL/XML?) > > * The array functions and indexes from contrib/intarray > and contrib/intagg made more general to work with other > data types. (I find these contrib modules quite useful) > > Annoyances: > > * more sane math with intervals. For example, try: > select '0.01 years'::interval, '0.01 months'::interval; > > Ease of use: > > * Nice defaults for autovacuum and checkpoints and bgwriter > that automatically avoid big I/O spikes by magically > distributing I/O in a nice way. > > Easier COPY for client library authors: > > * A way to efficiently insert many values like COPY from STDIN > from client libraries that don't support COPY from STDIN. > Perhaps it could happen through the apparently standards > compliant > "INSERT INTO table VALUES (1,2),(3,4),(5,6)" [feature id F641] > or perhaps through a new > COPY tablename FROM STRING 'a big string instead of stdin' > feature that would be easier for clients to support? > > It seems in most new client libraries COPY FROM STDIN > stays broken for quite a long time. Would a > alternative COPY FROM A_BIG_STRING be easier for them > to support and therefore available more often? > > Meta-stuff > > * A failover plus load-balancing (pgpool+slony?) > installer for dummies that handles simple cases. > > * A single place to find all the useful non-core stuff > like projects on pgfoundry, gborg, contrib, and > various other places around the net (PL/R PL/Ruby Postgis). > Perhaps if the postgresql website had a small wiki > somewhere where anyone could add links with a short > description to any such projects it'd be easier to > know what's out there... > > * Nice APIs and documentation [probably already exists] > to continue encouraging projects like PostGIS and PL/R > that IMHO are the biggest advantage of postgresql over > the commercial vendors' offerings. > > Oh, and seeing everyone else's response, I suppose I should > add MERGE though I haven't actually noticed a need yet. :-) > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
Ron Mayer wrote: > * more sane math with intervals. For example, try: > select '0.01 years'::interval, '0.01 months'::interval; Added to TODO: Fix SELECT '0.01 years'::interval, '0.01 months'::interval; -- 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, Pennsylvania19073
Josh Berkus <josh@agliodbs.com> writes: > Oh, yeah I forgot: > > -- windowing functions (e.g. RANK, RANK OVER, LAST 10) Include this URL or one like it in any TODO about this: http://publib.boulder.ibm.com/infocenter/rb63help/topic/com.ibm.redbrick.doc6.3/sqlrg/sqlrg36.htm#sii-06-62323 It would be wonderful having this stuff but I'll say just skimming it was giving me headaches imagining how much work it would be to do right. Just having a few windowing functions like rank() and functions like running averages would go a long way to making people happy though. -- greg
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Ron Mayer wrote:
>> * more sane math with intervals. For example, try:
>> select '0.01 years'::interval, '0.01 months'::interval;
> Added to TODO:
> Fix SELECT '0.01 years'::interval, '0.01 months'::interval;
Arguably, both of those things should be rejected as errors.
What is a fraction of a year? Or a month?
regards, tom lane
What everybody else said. :) But if it comes to voting... Anything to improve parallelism is good. Anything reducing blocking (ie: CLUSTER, VACUUM FULL) is good Improved handling of sort_mem (I think this will hit bizgres first) merge :) STATISTICS ON INDEXES! (specifically multi-field indexes) Multiple query plans for bound parameters. Materialized views. I don't know the history behind why Slony is trigger-based, but I think both materialized views and replication would benefit greatly from having a means to tie into WAL (or something similar) instead of using triggers. I would expect this to result in a dramatic speed improvement over triggers, since you would no longer be double-logging. A slick way to do this would be to tie-in to WAL writes that meet certain criteria (namely that they hit a specified table) and store those seperately on-disk. These would be played-back as needed. This mechanism should be useful for both replication and MViews. If you look at one of Oracle's replicaiton options, it's actually just a form of MViews that are on remote machines. Even if we stick with something trigger-based for now I think we should provide a base mechanism that works for both MViews and replication. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com 512-569-9461
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Ron Mayer wrote: > >> * more sane math with intervals. For example, try: > >> select '0.01 years'::interval, '0.01 months'::interval; > > > Added to TODO: > > > Fix SELECT '0.01 years'::interval, '0.01 months'::interval; > > Arguably, both of those things should be rejected as errors. > What is a fraction of a year? Or a month? What does the standard say we should do with these? Isn't this like interval division, which does work? -- 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, Pennsylvania19073
On Aug 27, 2005, at 2:45 AM, Heikki Linnakangas wrote:
>
> * support for Tutorial D as an alternative to SQL. It would be
> great for educational purposes.
++
I'd also like to see temporal/interval/period support a la Date/
Darwen/Lorentzos ("Temporal Data and the Relational Model").
Michael Glaesemann
grzm myrealbox com
On Fri, 26 Aug 2005, Heikki Linnakangas wrote: > * support for Tutorial D as an alternative to SQL. It would be great for > educational purposes. Hmm... we could call it POSTQUEL :-). Gavin
Michael Glaesemann said: > > On Aug 27, 2005, at 2:45 AM, Heikki Linnakangas wrote: > >> >> * support for Tutorial D as an alternative to SQL. It would be great >> for educational purposes. > > ++ > I disagree. This strikes me as something that belongs in a research project, not in the core, at least for now. cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
>>> * support for Tutorial D as an alternative to SQL. It would be great
>>> for educational purposes.
> This strikes me as something that belongs in a research project, not in the
> core, at least for now.
For better or worse, Postgres is a SQL engine; I can't imagine trying
to support two different query languages at the same time. When the
Berkeley guys ripped out PostQUEL and put in SQL, it was a major change,
and we are *still* trying to clean up leftover baggage from having
originally used a different language with different query semantics.
Even if Tutorial D were the greatest thing since sliced bread,
supporting it alongside SQL sounds totally impractical.
(Reality check: even supporting Oracle's flavor of SQL alongside ours
would be an incredible pain. Ask the EnterpriseDB guys how they're
doing on that ...)
regards, tom lane
alvherre@alvh.no-ip.org (Alvaro Herrera) writes: > Or, slightly different, what are people's most wanted features? - Vacuum Space Map - Maintain a map of recently-expired rows This allows vacuum to target specific pages for possible free space without requiring a sequential scan. - Deferrable unique constraint - Probably trivially easy would be to add an index to pg_listener - Tougher but better would be to have pg_listener be an in-memory structure rather than being physically represented as atable - MERGE / UPSERT - Config file "#includes" for postgresql.conf, pg_hba.conf - Some better ability to terminate backends - Automatically updatable views (per SQL 99) -- (format nil "~S@~S" "cbbrowne" "cbbrowne.com") http://cbbrowne.com/info/sap.html I am not a number! I am a free man!
> * optional interface which sends a row typeoid along with each row in a result set Oh, and 'select rowid, * from table' which returns special rowid column that just incrementally numbers each row. Chris
In article <4312783F.4050603@familyhealth.com.au>, Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: >> * optional interface which sends a row typeoid along with each row in a result set > Oh, and 'select rowid, * from table' which returns special rowid > column that just incrementally numbers each row. Why? It's a thing best handled at the client side, and we already have a way to do it server-side (temporary sequences).
On 29 Aug 2005 09:56:44 +0200, Harald Fuchs wrote: > Christopher Kings-Lynne writes: >> >> Oh, and 'select rowid, * from table' which returns special rowid >> column that just incrementally numbers each row. I think you can pretty much do that already by defining your own aggregate function. The obvious downside is that you need to put all the other columns in the GROUP BY clause. There might be some performance implications from the grouping, but I would presume that a rowid is most usefull in a situation where you are sorting anyway. I have to admit this part of the SQL spec is a bit over my head, but isn't grouping on an <empty grouping set> essentially a no-op? Implementing that would then take care of having to put all the coulmns in the GROUP BY clause. > Why? Because, although rarely necessary, it is frequently convenient to have such functionality on the server. Jochem
On Mon, 29 Aug 2005, Christopher Kings-Lynne wrote: > Oh, and 'select rowid, * from table' which returns special rowid column > that just incrementally numbers each row. In sql2003 there is a window function called ROW_NUMBER() that can be used to get numbers like that (one also need to specify the window to be the full table in this case). I think it can look like this (based on me reading the standard, i've not tested it in one of the other databases that support window functions): SELECT ROW_NUMBER() OVER (ORDER BY id), * FROM table; The over part specify that the whole result set is the window and that the row numbers should be assigned to the result in that order. In practice you want that order to be the same as the whole order I guess SELECT ROW_NUMBER() OVER (ORDER BY id), * FROM table ORDER BY id; Based on some googeling DB2 seems to allow OVER () while oracle does not and you need to specify the ORDER BY (or some other window definition) in the OVER part. Anyway, I just want to point out that row numbers are possible to get in sql2003, even if a simpler syntax like the above can also be useful. Maybe one can just extend sql2003 and let the OVER part be optional all together, and use SELECT ROW_NUMBER(), * FROM table; ps. A window is similar to group by, but you keep all rows in the result set. With group by you get one row from each group in the result set, -- /Dennis Björklund
Harald Fuchs wrote: > In article <4312783F.4050603@familyhealth.com.au>, > Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: >> >>Oh, and 'select rowid, * from table' which returns special rowid >>column that just incrementally numbers each row. > > Why? Perhaps Christopher meant "select row_number() OVER (...) as rowid" and then your "why" could be answered by "SQL Standard non-core feature T611"
On Thu, 2005-08-25 at 19:13 -0400, Alvaro Herrera wrote:
> Or, slightly different, what are people's most wanted features?
My approach to that question has been to try to group together
particular use cases. Currently, I see that PostgreSQL is great for web
applications ("OLTP") and getting better for decision support/data
warehousing. There are probably some finer grained groupings that could
be made too...
I'd be in favour of describing TODO and release history in terms of
those "possible applications", so people can see progress towards
particular solutions. Most of the features we add fall into the category
of "why would I want that?"
> Has PostgreSQL started slowing down in getting new features, and
> concentrating mostly on performance issues?
Most existing users (of any software product) want more admin
capabilities and better performance.
If you ask this question of existing users you will be biasing your
sample towards those viewpoints. You should ask the question of the
people who aren't yet using PostgreSQL ... which was how and why I
hacked away at PITR.
Best Regards, Simon Riggs
On 8/26/05, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
One feature, or rather set of features which was missing from the list and I think
it is important: i18n. :)
I mean, PostgreSQL has a number of good features concerning internationalization,
like UTF-8 support, transparent charset conversions, etc, but it also is area where
new users are likely to get bit. One of the most gotcha-prone areas in PostgreSQL
IMHO.
If you stick with English, its OK. If you want different language, say Polish, German,
whatever you'll probably careful enough to set a good locale. If you decide you
want to make a "hybrid" Polish-German database -- you may run into problems, like
indexes and ordering -- indexes are ordered using only one collation mechanism,
so you should probably use "C" locale. If you're unlucky -- you have to recreate
whole database. And then if you intend to use tsearch2, you have to set it up carefully
for given needs. I'm not saying that mysqlish approach of setting collate per table
would be a good solution.
Frankly I don't think there is an ideal solution for this.
Some time ago someone suggested using "universal" UTF-8 collation, which is
good for most languages (and not for Turkish :)) -- I believe I've seen a patch for
this on this list. Having some "one size fits most" solution could be helpful.
Anyway, the i18n problem is a child-age illness, once you get over with it, you're
most likely safe from it for the rest of your life. But some newbies may not get
through it. ;)
Regards,
Dawid
Or, slightly different, what are people's most wanted features?
One feature, or rather set of features which was missing from the list and I think
it is important: i18n. :)
I mean, PostgreSQL has a number of good features concerning internationalization,
like UTF-8 support, transparent charset conversions, etc, but it also is area where
new users are likely to get bit. One of the most gotcha-prone areas in PostgreSQL
IMHO.
If you stick with English, its OK. If you want different language, say Polish, German,
whatever you'll probably careful enough to set a good locale. If you decide you
want to make a "hybrid" Polish-German database -- you may run into problems, like
indexes and ordering -- indexes are ordered using only one collation mechanism,
so you should probably use "C" locale. If you're unlucky -- you have to recreate
whole database. And then if you intend to use tsearch2, you have to set it up carefully
for given needs. I'm not saying that mysqlish approach of setting collate per table
would be a good solution.
Frankly I don't think there is an ideal solution for this.
Some time ago someone suggested using "universal" UTF-8 collation, which is
good for most languages (and not for Turkish :)) -- I believe I've seen a patch for
this on this list. Having some "one size fits most" solution could be helpful.
Anyway, the i18n problem is a child-age illness, once you get over with it, you're
most likely safe from it for the rest of your life. But some newbies may not get
through it. ;)
Regards,
Dawid
* Updatable Views per SQL * INTERVAL data type per SQL * BLOB/CLOB data type per SQL * Faster bulk load * Remove "current transaction is aborted, commands ignored ..." * Compile with MSVC on Win32 platforms. MySQL support it. * Thread safety libpq, ecpg. -- Regards, William ZHANG
Oh, I remembered another of my personal feature requests for 8.2 :D * Fix planning and execution of set operations so that they're not tragically slow. eg. rewriting into outer joins, etc. Chris
Am Freitag, 26. August 2005 01:13 schrieb Alvaro Herrera: > Or, slightly different, what are people's most wanted features? For entertainment, here is a summary the most requested features: 1. MERGE command 2. Table partitioning 2. Materialized views 2. Updatable views 5. Index-organized tables, index-only access 6. Recursive queries 6. Window functions 8. Debuggable PL/pgSQL 8. Better bulk load 8. Multimaster replication 8. Database assertions 8. Multi-threaded/process query execution 8. CUBE and ROLLUP 8. Concurrent vacuum So there is plenty of work left... -- Peter Eisentraut http://developer.postgresql.org/~petere/
FWIW, I think a lot of people didn't "me too" on all the features they want, so I wouldn't put too much weight on the ranking here... On Mon, Sep 05, 2005 at 05:43:16PM +0200, Peter Eisentraut wrote: > Am Freitag, 26. August 2005 01:13 schrieb Alvaro Herrera: > > Or, slightly different, what are people's most wanted features? > > For entertainment, here is a summary the most requested features: > > 1. MERGE command > > 2. Table partitioning > > 2. Materialized views > > 2. Updatable views > > 5. Index-organized tables, index-only access > > 6. Recursive queries > > 6. Window functions > > 8. Debuggable PL/pgSQL > > 8. Better bulk load > > 8. Multimaster replication > > 8. Database assertions > > 8. Multi-threaded/process query execution > > 8. CUBE and ROLLUP > > 8. Concurrent vacuum > > So there is plenty of work left... > > -- > Peter Eisentraut > http://developer.postgresql.org/~petere/ > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461