Thread: 7.5 features

7.5 features

From
Bruce Momjian
Date:
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
 


Re: 7.5 features

From
Bob.Henkel@hartfordlife.com
Date:




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.
 
*************************************************************************



How to Welcome Windows Users (was Re: 7.5 features)

From
Richard Huxton
Date:
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


Re: 7.5 features

From
Martin Marques
Date:
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
-----------------------------------------------------------------



Re: How to Welcome Windows Users (was Re: 7.5 features)

From
"Marc G. Fournier"
Date:
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


Re: 7.5 features

From
"Marc G. Fournier"
Date:
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


Re: 7.5 features

From
Richard Huxton
Date:
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


Re: 7.5 features

From
Rod Taylor
Date:
> > 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.




Re: 7.5 features

From
Bruce Momjian
Date:
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
 


Re: 7.5 features

From
"Matthew T. O'Connor"
Date:
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...)




Re: 7.5 features

From
Tom Lane
Date:
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


Re: How to Welcome Windows Users (was Re: 7.5 features)

From
"scott.marlowe"
Date:
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.



Re: 7.5 features

From
Bruce Momjian
Date:
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
 


Re: 7.5 features

From
Tom Lane
Date:
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


Re: 7.5 features

From
"Andrew Dunstan"
Date:
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




Re: 7.5 features

From
Bruce Momjian
Date:
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
 


Re: 7.5 features

From
"Marc G. Fournier"
Date:
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


Re: 7.5 features

From
Andrew Dunstan
Date:
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


Re: 7.5 features

From
Bruce Momjian
Date:
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
 


Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Matthew T. O'Connor"
Date:
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




Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Andrew Sullivan
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Tom Lane
Date:
"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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Andrew Dunstan
Date:

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



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Tom Lane
Date:
"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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: 7.5 features

From
"Thomas Hallgren"
Date:
""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



Re: 7.5 features

From
"Andrew Dunstan"
Date:
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




Re: Call for 7.5 feature completion

From
Andrew Sullivan
Date:
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


Re: Call for 7.5 feature completion

From
Hans-Jürgen Schönig
Date:
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



Re: 7.5 features

From
"Tom Lane"
Date:
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




Re: Call for 7.5 feature completion

From
Alvaro Herrera
Date:
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)


Re: 7.5 features

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Hannu Krosing
Date:
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





Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Christopher Kings-Lynne
Date:
> 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



Re: Call for 7.5 feature completion

From
Rod Taylor
Date:
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.



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Bruno Wolff III
Date:
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.


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Hans-Jürgen Schönig
Date:
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



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #




Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Robert Treat
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Mario Weilguni
Date:
> 
> 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.


Re: Call for 7.5 feature completion

From
Mike Mascari
Date:
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



Re: Call for 7.5 feature completion

From
Simon Riggs
Date:
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



Re: Call for 7.5 feature completion

From
Gaetano Mendola
Date:
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





Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
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

Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
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

Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
>
> 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

Re: Call for 7.5 feature completion

From
Greg Stark
Date:
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



Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Mike Mascari
Date:
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





Re: Call for 7.5 feature completion

From
Greg Stark
Date:
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



Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #



Re: Call for 7.5 feature completion

From
Jan Wieck
Date:
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 #



Re: Call for 7.5 feature completion

From
Tatsuo Ishii
Date:
> 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


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
> 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



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Christopher Kings-Lynne
Date:
> 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



Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
<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>

Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Mike Mascari
Date:
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





Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
>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



Re: Call for 7.5 feature completion

From
"Andrew Dunstan"
Date:
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





Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Bruno Wolff III
Date:
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.


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
>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



Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Hans-Jürgen Schönig
Date:
> 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



Re: Call for 7.5 feature completion

From
Mario Weilguni
Date:
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


Re: Call for 7.5 feature completion

From
Mario Weilguni
Date:
> 
> 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


Re: Call for 7.5 feature completion

From
Greg Copeland
Date:
>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




Re: Call for 7.5 feature completion

From
Mario Weilguni
Date:
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


Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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.



Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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.



Re: Call for 7.5 feature completion

From
Tatsuo Ishii
Date:
> 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


Re: Call for 7.5 feature completion

From
Marko Karppinen
Date:
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



Re: Call for 7.5 feature completion

From
Richard Huxton
Date:
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


Re: Call for 7.5 feature completion

From
Robert Treat
Date:
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



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
>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



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
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>

Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Andrew Sullivan
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Greg Copeland
Date:
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




Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
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>

Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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.



Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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.



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
>
> 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

Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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.



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
>
>
> 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

Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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?



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:

> 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



Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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.



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:

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


Re: Call for 7.5 feature completion

From
"Greg Sabino Mullane"
Date:
-----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-----




Re: Call for 7.5 feature completion

From
Christopher Kings-Lynne
Date:
> 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


Re: Call for 7.5 feature completion

From
Lamar Owen
Date:
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


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
> 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



Re: Call for 7.5 feature completion

From
Lamar Owen
Date:
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


Re: Call for 7.5 feature completion

From
"Marc G. Fournier"
Date:
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


Re: Call for 7.5 feature completion

From
Tatsuo Ishii
Date:
> 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


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
>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



Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
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>

Re: Call for 7.5 feature completion

From
Richard Huxton
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Tom Lane
Date:
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


Re: Call for 7.5 feature completion

From
Tom Lane
Date:
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


Re: Call for 7.5 feature completion

From
Alvaro Herrera
Date:
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"


Re: Call for 7.5 feature completion

From
Andrew Dunstan
Date:
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


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
  > 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



Re: Call for 7.5 feature completion

From
Gaetano Mendola
Date:
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





Re: Call for 7.5 feature completion

From
Robert Treat
Date:
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



Re: Call for 7.5 feature completion

From
David Garamond
Date:
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


Re: Call for 7.5 feature completion

From
Gaetano Mendola
Date:
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






Re: Call for 7.5 feature completion

From
Mark Kirkwood
Date:
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" :-)
>


From
"Matthew T. O'Connor"
Date:
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



Re:

From
Tom Lane
Date:
"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


Re:

From
"Marc G. Fournier"
Date:
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


Re:

From
Mark Kirkwood
Date:
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.
>
>  
>


Re: Call for 7.5 feature completion

From
Alvaro Herrera
Date:
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)


Re: Call for 7.5 feature completion

From
"Joshua D. Drake"
Date:
> 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/


Re: Call for 7.5 feature completion

From
Gavin Sherry
Date:
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


Re: Call for 7.5 feature completion

From
"J. Andrew Rogers"
Date:
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




Re: Call for 7.5 feature completion

From
Josh Berkus
Date:
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


Re: Call for 7.5 feature completion

From
Andrew Dunstan
Date:

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


Re: Call for 7.5 feature completion

From
Josh Berkus
Date:
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


Re: Call for 7.5 feature completion

From
Rod Taylor
Date:
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.
 

-- 



Re: Call for 7.5 feature completion

From
Andrew Dunstan
Date:

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


Re: Call for 7.5 feature completion

From
Rod Taylor
Date:
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.

-- 



Re: Call for 7.5 feature completion

From
Christopher Kings-Lynne
Date:
> 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



Re: Call for 7.5 feature completion

From
Christopher Kings-Lynne
Date:
> 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



Re: Call for 7.5 feature completion

From
Nicholas Walker
Date:
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.


Re: Call for 7.5 feature completion

From
Mike Mascari
Date:
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


Re: Call for 7.5 feature completion

From
Josh Berkus
Date:
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


Re: Call for 7.5 feature completion

From
Dennis Bjorklund
Date:
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



Re: Call for 7.5 feature completion

From
Hannu Krosing
Date:
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>



Re: Call for 7.5 feature completion

From
David Fetter
Date:
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!


Re: Call for 7.5 feature completion

From
Stephen Frost
Date:
* Alvaro Herrera (alvherre@alvh.no-ip.org) wrote:
> Or, slightly different, what are people's most wanted features?

MERGE.
Stephen

Re: Call for 7.5 feature completion

From
Nicholas Walker
Date:
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...


Re: Call for 7.5 feature completion

From
Matt Miller
Date:
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)?


Re: Call for 7.5 feature completion

From
Heikki Linnakangas
Date:
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


Re: Call for 7.5 feature completion

From
Ron Mayer
Date:
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. :-)


Re: Call for 7.5 feature completion

From
Junaili Lie
Date:
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
>


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Greg Stark
Date:
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



Re: Call for 7.5 feature completion

From
Tom Lane
Date:
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


Re: Call for 7.5 feature completion

From
"Jim C. Nasby"
Date:
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


Re: Call for 7.5 feature completion

From
Bruce Momjian
Date:
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
 


Re: Call for 7.5 feature completion

From
Michael Glaesemann
Date:
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




Re: Call for 7.5 feature completion

From
Gavin Sherry
Date:
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


Re: Call for 7.5 feature completion

From
"Andrew Dunstan"
Date:
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




Re: Call for 7.5 feature completion

From
Tom Lane
Date:
"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


Re: Call for 7.5 feature completion

From
Chris Browne
Date:
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!


Re: Call for 7.5 feature completion

From
Christopher Kings-Lynne
Date:
> * 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



Re: Call for 7.5 feature completion

From
Harald Fuchs
Date:
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).



Re: Call for 7.5 feature completion

From
Jochem van Dieten
Date:
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


Re: Call for 7.5 feature completion

From
Dennis Bjorklund
Date:
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



Re: Call for 7.5 feature completion

From
Ron Mayer
Date:
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"


Re: Call for 7.5 feature completion

From
Simon Riggs
Date:
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





Re: Call for 7.5 feature completion

From
Dawid Kuroczko
Date:
On 8/26/05, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
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

Re: Call for 7.5 feature completion

From
"William ZHANG"
Date:
* 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




Re: Call for 7.5 feature completion

From
Christopher Kings-Lynne
Date:
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



Re: Call for 7.5 feature completion

From
Peter Eisentraut
Date:
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/


Re: Call for 7.5 feature completion

From
"Jim C. Nasby"
Date:
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