Re: Call for 7.5 feature completion

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tuesday 27 April 2004 14:27, Bruce Momjian wrote:
> Here are features that are being worked on, hopefully for 7.5:
>
> o tablespaces (Gavin)
> o nested transactions (Alvaro)
> o two-phase commit (Heikki Linnakangas)
> o integrated pg_autovacuum (O'Connor)
> o PITR (Riggs)
> o Win32 (Claudio, Magnus)
>
> If we get the majority of them, and I think we will, this will be a
> great release.

Sounds like the biggest release since 7.0 to me, and all good stuff. I do have
a nagging concern with the Windows support though. I'm guessing most people
running Windows servers will either be running php on top, or have windows
clients. AFAIK this means .NET or ODBC, and for older Access-based systems
upgrading definitely ODBC.

Dave Page has bravely stepped into the breach to maintain the ODBC driver, but
the niggles in it will generate a flood of support messages as Windows users
test it out. Basically, I'm asking what would need to be done technically for
the ODBC driver, and is there anything a non-hacker can do to help?

--
Richard Huxton
Archonet Ltd

El Tuesday 27 April 2004 10:27, Bruce Momjian escribió:
> Here are features that are being worked on, hopefully for 7.5:
>
> o tablespaces (Gavin)
> o nested transactions (Alvaro)
> o two-phase commit (Heikki Linnakangas)
> o integrated pg_autovacuum (O'Connor)
> o PITR (Riggs)
> o Win32 (Claudio, Magnus)
>
> If we get the majority of them, and I think we will, this will be a
> great release.

How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs
(depending on how stable it gets)?

--
11:21:02 up 49 days, 15:45, 4 users, load average: 0.53, 0.68, 0.71
-----------------------------------------------------------------
Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------

On Tue, 27 Apr 2004, Richard Huxton wrote:

> Dave Page has bravely stepped into the breach to maintain the ODBC
> driver, but the niggles in it will generate a flood of support messages
> as Windows users test it out. Basically, I'm asking what would need to
> be done technically for the ODBC driver, and is there anything a
> non-hacker can do to help?

First question ... what niggles?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Tue, 27 Apr 2004, Martin Marques wrote:

> El Tuesday 27 April 2004 10:27, Bruce Momjian escribió:
> > Here are features that are being worked on, hopefully for 7.5:
> >
> > o tablespaces (Gavin)
> > o nested transactions (Alvaro)
> > o two-phase commit (Heikki Linnakangas)
> > o integrated pg_autovacuum (O'Connor)
> > o PITR (Riggs)
> > o Win32 (Claudio, Magnus)
> >
> > If we get the majority of them, and I think we will, this will be a
> > great release.
>
> How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs
> (depending on how stable it gets)?

Zero chance ... Slony-I is *a* replication solution, not *the*
replication solution ... unless someone ever comes up with an 'end all and
be all' replication solution (which, personally, I don't think will ever
happen), we should not be officially endorsing any one replication
solution ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Tuesday 27 April 2004 15:22, Martin Marques wrote:
>
> How's Jans' Slowny-I doing? Any chance of getting it at least in the
> contribs (depending on how stable it gets)?

There was a post from Jan the other day (on General iirc) - I think he's
looking for testers at the moment before he goes to feature-freeze.

--
Richard Huxton
Archonet Ltd

> > How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs
> > (depending on how stable it gets)?
>
> Zero chance ... Slony-I is *a* replication solution, not *the*
> replication solution ... unless someone ever comes up with an 'end all and

Not to mention Jan doesn't want it to be in contrib as that would imply
it was version specific. One of the more popular uses of Slony will be
version upgrades with minimal downtime.

Martin Marques wrote:
> El Tuesday 27 April 2004 10:27, Bruce Momjian escribi?:
> > Here are features that are being worked on, hopefully for 7.5:
> >
> > o tablespaces (Gavin)
> > o nested transactions (Alvaro)
> > o two-phase commit (Heikki Linnakangas)
> > o integrated pg_autovacuum (O'Connor)
> > o PITR (Riggs)
> > o Win32 (Claudio, Magnus)
> >
> > If we get the majority of them, and I think we will, this will be a
> > great release.
>
> How's Jans' Slowny-I doing? Any chance of getting it at least in the contribs
> (depending on how stable it gets)?

Yep, I forgot that, though it is independent of the 7.5 release. I
think Jan will make a final release in a few months. I also should
mention server-side java, again also an independent project.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, 2004-04-27 at 09:27, Bruce Momjian wrote:
> Here are features that are being worked on, hopefully for 7.5:
>
> o tablespaces (Gavin)
> o nested transactions (Alvaro)
> o two-phase commit (Heikki Linnakangas)
> o integrated pg_autovacuum (O'Connor)
> o PITR (Riggs)
> o Win32 (Claudio, Magnus)
>
> If we get the majority of them, and I think we will, this will be a
> great release.

Dare I even mention calling it 8.0? (ducks and runs for cover...)

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Here are features that are being worked on, hopefully for 7.5:
> o tablespaces (Gavin)
> o nested transactions (Alvaro)
> o two-phase commit (Heikki Linnakangas)
> o integrated pg_autovacuum (O'Connor)
> o PITR (Riggs)
> o Win32 (Claudio, Magnus)

Not to rain on the parade, but the *only* one of these I have any
confidence in seeing for 7.5 is the last (Windows port). The others
are still mostly or entirely handwaving, and I do not think we will
hold up the release for them once the Windows port starts looking
stable enough to beta-test.

regards, tom lane

On Tue, 27 Apr 2004, Richard Huxton wrote:

> On Tuesday 27 April 2004 14:27, Bruce Momjian wrote:
> > Here are features that are being worked on, hopefully for 7.5:
> >
> > o tablespaces (Gavin)
> > o nested transactions (Alvaro)
> > o two-phase commit (Heikki Linnakangas)
> > o integrated pg_autovacuum (O'Connor)
> > o PITR (Riggs)
> > o Win32 (Claudio, Magnus)
> >
> > If we get the majority of them, and I think we will, this will be a
> > great release.
>
> Sounds like the biggest release since 7.0 to me, and all good stuff. I do have
> a nagging concern with the Windows support though. I'm guessing most people
> running Windows servers will either be running php on top, or have windows
> clients. AFAIK this means .NET or ODBC, and for older Access-based systems
> upgrading definitely ODBC.
>
> Dave Page has bravely stepped into the breach to maintain the ODBC driver, but
> the niggles in it will generate a flood of support messages as Windows users
> test it out. Basically, I'm asking what would need to be done technically for
> the ODBC driver, and is there anything a non-hacker can do to help?

I would say the OLE-DB driver would be nice to have ready to go. There
are apparently a few projects on source forge to make one that are making
good progress, and it would be nice to have a fairly workable solution
about the time 7.5 rolls out.

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

Tom Lane said:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>> What we really need is for these folks to start finalizing their
>> patches and get them submitted.
>
> Eggzackle ... my point is that I see the win32 train leaving the
> station pretty soon, and I don't see anyone else ready to get on board.
>
>

Not quite yet - yesterday I got hold of a windows box for the first time
in months and had significant building problems (the symlink problem and
others). This needs to be robust. I will be sending in some fixes in due
course.

Is it time to set a tentative target date for a feature freeze, though?
Perhaps some time in mid to late June would be good. That way people could
work to a known timeline.

cheers

andrew

Andrew Dunstan wrote:
> Tom Lane said:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Thu, 29 Apr 2004, Andrew Dunstan wrote:

> Tom Lane said:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

>Right now, the feature freeze is tentative for 1st of June, which has been
>thrown around a few times already ...
>
>
>

If it has I've missed it - always seemed somewhat vaguer to me.

Thanks

andrew

Marc G. Fournier wrote:
> On Thu, 29 Apr 2004, Andrew Dunstan wrote:
>
> > Tom Lane said:
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

> Yes, it was vague. The question is now that we are a month away, do we
> want to target June 1, mid-June, or July 1.
>
> Some are saying that once Win32 is ready, it will justify a release even
> if the other features are not ready.

I think we should have this conversation once the win32 code is ready.
Since the beta period / release schedule usually takes several months in
and of it self, anyone working on an item from the list below is going
to lose a lot of steam if they are 80% done but get excluded from 7.5
and have to wait out the release process.

> Looking at the list:
>
> o tablespaces (Gavin)
> o nested transactions (Alvaro)
> o two-phase commit (Heikki Linnakangas)
> o integrated pg_autovacuum (O'Connor)
> o PITR (Riggs)
> o Win32 (Claudio, Magnus)
> o replication (Sloney)
> o server-side Java
>
> o integrated pg_autovacuum (O'Connor)
>
> Unknown. We need fixes for temp tables for 7.4.3 too.

Yes I know, starting next week, I will have some time to work on this.
I will fix the temp table problem first, then the 7.5 only work. FYI, I
do fully intend on getting pg_autovacuum integrated for 7.5, even with a
June 1 deadline.

Matthew O'Connor

Matthew T. O'Connor wrote:
> Bruce Momjian wrote:
>
> > Yes, it was vague. The question is now that we are a month away, do we
> > want to target June 1, mid-June, or July 1.
> >
> > Some are saying that once Win32 is ready, it will justify a release even
> > if the other features are not ready.
>
> I think we should have this conversation once the win32 code is ready.
> Since the beta period / release schedule usually takes several months in
> and of it self, anyone working on an item from the list below is going
> to lose a lot of steam if they are 80% done but get excluded from 7.5
> and have to wait out the release process.

Agreed, we will have to wait for Win32 to be completed, but Win32 also
needs to try to hit that date. We can't drive the entire release
process on one feature addition. What I am saying is that Win32 needs
to focus on meeting that date too.

The bottom line is that folks need to get their work completed or they
will miss the ability to have their work in 7.5. It has happened
before, and it will probably happen again in this release that some
folks will not complete things in time.

7.4 was 2003-11-17 and given our usual timeline June 1 seems like a good
cutoff.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Thu, 29 Apr 2004, Bruce Momjian wrote:
>
> > Andrew Dunstan wrote:
> > > Marc G. Fournier wrote:
> > >
> > > >Right now, the feature freeze is tentative for 1st of June, which has been
> > > >thrown around a few times already ...
> > > >
> > > >
> > > >
> > >
> > > If it has I've missed it - always seemed somewhat vaguer to me.
> >
> > Yes, it was vague. The question is now that we are a month away, do we
> > want to target June 1, mid-June, or July 1.
>
> Target June 1st ... when May 29th or so rolls around, we can then
> determine whether or not we need to extend it, and why. We've gone down
> this road too many times, where we've extended cause a patch was "right
> around the corner" that finally came in a month later ...
>
> The point of a deadline is that you don't make it floating ... if the
> deadline arrives, and someone can justify extending it a few days to a
> week, then so be it ...

No. We tried that in the past and we ended up extending it in pieces
several times. The effect was that we delayed feature freeze by a month
or two, and other features never got developed in that timeframe. I
remember SMP fixes for 7.3 as causing that problem. We didn't do that
for 7.4 and it was better.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)crankycanuck(dot)ca

Andrew Sullivan wrote:
> On Thu, Apr 29, 2004 at 01:26:07PM -0400, Bruce Momjian wrote:
> > o nested transactions (Alvaro)
> >
> > Has submitted patches that are under review. He has the nesting of
> > BEGIN done, and storage manager subtransaction handling. I think he
> > needs to do pg_subtrans system table and error recovery. He says he can
> > finish in time.
> >
> > o two-phase commit (Heikki Linnakangas)
> >
> > Has patches and is waiting for Alvaro's patches to be applied. Not sure
>
> If 2PC patches are ready and nested transactions not, is it worth
> considering applying 2PC when subtransactions aren't ready? I
> appreciate the work that will cause, so I'm not saying this lightly.
> It's probably too early to make that decision now, but I'd suggest
> keeping it in mind in case something goes off the rails.

2-PC hasn't actually been posted for applicaiton, while Alvaro's have.
They know they will conflict and 2PC wanted to wait for Alvaro's
changes.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> *If* June 1st comes along, and Win32 isn't ready, there is nothing wrong
> with freezing the code *except* for a pending Win32 patch ...

Yeah there is ...

In the first place it's unfair to other developers to make schedule
slips at the last moment, and especially to *plan* to do so. I would
prefer we determine at least two weeks, preferably a month, in advance
whether there is going to be a schedule change. I think it's entirely
appropriate to decide now whether we are going to hold to June 1 feature
freeze or slip it. That gives other people a chance to do useful work
while we approach the deadline.

In the second, any Win32 issues that remain unresolved as of June 1
are likely to be major enough (in terms of code impact) that we can't
realistically contemplate slipping in post-beta patches for them.
The fallback position is going to have to be no (supported) Win32 port
in 7.5, not "we'll fix this in beta".

regards, tom lane

On Thu, 29 Apr 2004, Tom Lane wrote:

> "Marc G. Fournier" <scrappy(at)postgresql(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

>
>Personally, I think there are alot of large features that ppl have been
>hard at getting complete in time for June 1st that we should stick to it,
>else we're going to end up with 'yet another release' delayed in hopes
>that the outstanding bugs in Win32 will get fixed in a reasonable amount
>of time ...
>
>June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd
>to the Win32 Native port being finished ...
>
>If that means 8.0 happens to be September 1st, so be it ...
>
>
>

Bruce agreed that this had been vague before today, so if people have
had this date in mind and have been working to it, perhaps they have
some telepathic abilities I lack ...

We missed on PITR *and* Win32 last year. ISTM there's a bit of a
credibility issue at stake, so it might well be worth taking a couple of
weeks leeway if that's what is required.

The other point, especially about Win32, is to see if we can spread the
load a bit. Perhaps Claudio, Magnus, Merlin and Bruce should start
trying to farm out specific tasks. I for one will be very upset if it
misses this release.

cheers

andrew

Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Thu, 29 Apr 2004, Bruce Momjian wrote:
>
> > Marc is concerned that folks will not work hard to meet a deadline and
> > will slack off if we push thing to July 1.
>
> I don't think I'm so muc worried about that as under-estimating the amount
> of time required to finish them ... its not like *that's* never happened
> before, and with something as big as some of the features that are in the
> works, and with some of the major show-stoppers that the Win32 port has
> brought up, I can seriously see '1 month' being drawn out further ...
>
> > Win32 has continued on a steady pace for six months now.
>
> Be honest ... 6 months ago, did you believe the Win32 work would have
> taken >6 months? How many of the current issues could you have
> anticipated? How many will crop up in the next month?

Honestly, I didn't think we would be this far by now (we had regression
tests mostly passing 4-6 weeks ago), and the win32 status page hasn't
added a new TODO item in quite some time. I thought we would be hacking
Win32 all through 7.5 beta and releasing something after 7.5 as a 7.5
plus patches release but we are far enough along to hit 7.5 by feature
freeze.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Thu, 29 Apr 2004, Tom Lane wrote:
>> In the first place it's unfair to other developers to make schedule
>> slips at the last moment, and especially to *plan* to do so.

> Isn't it equally unfair to slip the scheduale that developers that have
> been working on some large features (PITR, 2PC immediately coming to mind)
> have been working towards based on a deadline? If Win32 that much more
> important then those other features?

As you well know, I have no use for the Win32 port at all ;-). However,
of the "major features" that Bruce just listed, the Win32 port is the
only one I consider really likely to appear in 7.5; sure it needs major
work yet, but the others are still in the vaporware-till-proven-otherwise
category. Certainly they are not solid enough to justify making
schedule decisions on the basis of "this will probably be ready by date X".

I am willing to adjust the freeze deadline now to make it more probable
that at least one of those major features will really make it into 7.5.
The realities are that the Win32 port should determine any such schedule
decision, because nothing else is close enough to the finish line to
justify considering its needs instead.

I guess my point is really "do you want to freeze on June 1 if *none*
of these features are done?"

regards, tom lane

Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Thu, 29 Apr 2004, Tom Lane wrote:
>
> > I guess my point is really "do you want to freeze on June 1 if *none* of
> > these features are done?"
>
> No, I agree that that would be foolish ... but there has also been alot
> done on the code over the past few months that even *one* of those
> features should be enough to put it over the top ...

But we should have at least one done before setting a freeze date, and
the freeze date should be one month in the future. Right now we have
none.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Fri, 30 Apr 2004, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> > > On Thu, 29 Apr 2004, Tom Lane wrote:
> > >
> > > > I guess my point is really "do you want to freeze on June 1 if *none* of
> > > > these features are done?"
> > >
> > > No, I agree that that would be foolish ... but there has also been alot
> > > done on the code over the past few months that even *one* of those
> > > features should be enough to put it over the top ...
> >
> > But we should have at least one done before setting a freeze date, and
> > the freeze date should be one month in the future. Right now we have
> > none.
>
> Now, that logic *doesn't* follow ... freeze date == that one feature makes
> more sense ... or freeze date == one month from May 1st *or* one feature,
> whichever is longer makes sense ...

But we don't want to have all our developers controlled by one feature
being completed. It isn't fair. They should get a good warning about
freeze starting.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Fri, 30 Apr 2004, Bruce Momjian wrote:
>
> > But we don't want to have all our developers controlled by one feature
> > being completed. It isn't fair. They should get a good warning about
> > freeze starting.
>
> Nor is it fair to extend the development cycle indefinitely waiting for
> that one feature in the first place ... there is *nothing* that states
> that the 7.6 dev cycle is nice and short for a change ...

Agreed. I say we wait for _a_ major feature completed, or X major
features.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

""Andrew Dunstan"" <andrew(at)dunslane(dot)net> wrote in message
news:3660(dot)24(dot)211(dot)141(dot)25(dot)1083248588(dot)squirrel(at)www(dot)dunslane(dot)net(dot)(dot)(dot)
> 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.

Kind regards,

Thomas Hallgren

Thomas Hallgren said:
> ""Andrew Dunstan"" <andrew(at)dunslane(dot)net> wrote in message
> news:3660(dot)24(dot)211(dot)141(dot)25(dot)1083248588(dot)squirrel(at)www(dot)dunslane(dot)net(dot)(dot)(dot)
> > Not quite yet - yesterday I got hold of a windows box for the first
> > time
>> in months and had significant building problems (the symlink problem
>> and others). This needs to be robust. I will be sending in some fixes
>> in due course.
> A patch fixing those problems have already been submitted by Claudio
> Natoli. Perhaps you already knew that.
>

There's yet to be agreement on how to fix this. See the hack that I used
yesterday on the -win32 list.

cheers

andrew

On Thu, Apr 29, 2004 at 09:30:12PM -0300, Marc G. Fournier wrote:
>
> June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd
> to the Win32 Native port being finished ...

I seem to remember the same argument at 7.4 time. I don't use
Windows, I think it's a bletcherous system, but I really think
delaying the Windows port Yet Again will make the project almost
completely irrelevant to a significant audience. I completely agree
that it'd be a bad idea to slip indefinitely on the basis of "Windows
is still not ready," but if it's a matter of changing freeze date by
a month, given the long notice, why is that a bad thing?

The Windows port is _extremely_ important for a lot of people, and I
think it'd be short sighted to ignore that constituency, even if they
are mostly not here yet.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca

Andrew Dunstan wrote:
>
>
> Marc G. Fournier wrote:
>
>>
>> Personally, I think there are alot of large features that ppl have been
>> hard at getting complete in time for June 1st that we should stick to it,
>> else we're going to end up with 'yet another release' delayed in hopes
>> that the outstanding bugs in Win32 will get fixed in a reasonable amount
>> of time ...
>>
>> June 1st, let's do beta for 7.5 and then branch onto 8.0, with 8.0 key'd
>> to the Win32 Native port being finished ...
>>
>> If that means 8.0 happens to be September 1st, so be it ...
>>
>>
>>
>
> Bruce agreed that this had been vague before today, so if people have
> had this date in mind and have been working to it, perhaps they have
> some telepathic abilities I lack ...
>
> We missed on PITR *and* Win32 last year. ISTM there's a bit of a
> credibility issue at stake, so it might well be worth taking a couple of
> weeks leeway if that's what is required.
>
> The other point, especially about Win32, is to see if we can spread the
> load a bit. Perhaps Claudio, Magnus, Merlin and Bruce should start
> trying to farm out specific tasks. I for one will be very upset if it
> misses this release.
>
> cheers
>
> andrew

This is exactly the point ...
If you go to a conference you will ALWAYS face the same questions:

- when can we have sync. replication and failover
- when can we have PITR
- when can we have win32

People won't believe us anymore if you keep telling them "in the next
release".
If a feature freeze is made on August 1st or even later it would be ok
because nobody is doing major database changes in summer anyway.
Currently I cannot see a major reason why people should upgrade to 7.5
(ARC and so forth are great but they are no killer features). Maybe in
this case it is worth waiting for 2 major features to make it into the
release (let's say PITR + nested transactions or win32 and pitr or 2pc
and nested transactions). This would point out that significant progress
is made.

Regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/2952/30706 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at

On Sat, May 01, 2004 at 09:03:03AM +0200, Hans-Jürgen Schönig wrote:

> If a feature freeze is made on August 1st or even later it would be ok
> because nobody is doing major database changes in summer anyway.

You seem to forget that half of the world is not in summer on August
1st. I admit that 90% of the developers are not on _this_ half of the
world though ;-) My point is that not necessarily development will stop
at that time. Moreover, if there is nobody to test the beta, what good
does to have a feature freeze?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Just treat us the way you want to be treated + some extra allowance
for ignorance." (Michael Brusser)

On Wed, 12 May 2004, Jan Wieck wrote:

> Can we please make "move all replication software out of the release" an
> official open item for the 7.5 release?

Agreed ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Bruce Momjian wrote:

> Tom Lane wrote:
>> "Marc G. Fournier" <scrappy(at)postgresql(dot)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(at)Yahoo(dot)com #

Jan Wieck wrote:
> We have ARC, the background writer and vacuum delay, and people even ask
> me for backports of that (I have one for vacuum delay, but refuse to
> make one for the others). How long do you want to delay that being ready
> for production? Do you really think people that are suffering from the
> fact that checkpoints, vacuum runs and pg_dumps bog down their machines
> to the state where simple queries take several seconds care that much
> for any Win32 port? Do you think it is a good sign for those who have
> been our traditional Unix user base that we delay the important
> enhancements that they need because we want to attract a lot of
> non-professional users in Windows land? I think that is the wrong signal
> to send. However important for marketing the Win32 port is, there are
> other things in the pipeline that are important for those users we have
> won already long time ago. Let's rather not lose them.

Sure those are nifty enhancements, but they are not really new features.
I would rather call them performance enhancements. Sure, there are some
folks who can't use PostgreSQL without them, but they are not like PITR
or nested transactions where you really can't easily work around the
limitation.

Sure, you can work around the lack of a Win32 port with Cygwin, and
maybe use replication in place of PITR, but the big question is are you
hitting a large precentage of users with an enhancement. I am sure i
can get some "me too's" for your improvements, but it doesn't represeent
dramatic new functionality for PostgreSQL.

I personally don't think Win32 is enough of a new feature either, but
others disagree.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian kirjutas P, 16.05.2004 kell 22:45:
> Jan Wieck wrote:
> > We have ARC, the background writer and vacuum delay, and people even ask
> > me for backports of that (I have one for vacuum delay, but refuse to
> > make one for the others). How long do you want to delay that being ready
> > for production? Do you really think people that are suffering from the
> > fact that checkpoints, vacuum runs and pg_dumps bog down their machines
> > to the state where simple queries take several seconds care that much
> > for any Win32 port? Do you think it is a good sign for those who have
> > been our traditional Unix user base that we delay the important
> > enhancements that they need because we want to attract a lot of
> > non-professional users in Windows land? I think that is the wrong signal
> > to send. However important for marketing the Win32 port is, there are
> > other things in the pipeline that are important for those users we have
> > won already long time ago. Let's rather not lose them.
>
> Sure those are nifty enhancements, but they are not really new features.
> I would rather call them performance enhancements.

But it seems that they _are_ new enough features not to be included in
point releases (like 7.4.3).

> Sure, there are some
> folks who can't use PostgreSQL without them, but they are not like PITR
> or nested transactions where you really can't easily work around the
> limitation.

If you need a 24h non-stop database for global business, it is not
acceptable to have 30-minute periods of very slow queries resulting in
dropped connections. The only way to work around it without Jan's
patches is not to run vacuum at all, but this is a lousy longer-term
solution.

> Sure, you can work around the lack of a Win32 port with Cygwin, and
> maybe use replication in place of PITR, but the big question is are you
> hitting a large precentage of users with an enhancement.

I'm not sure that the initial version of PITR will be a good replacement
for replication.

> I am sure i
> can get some "me too's" for your improvements, but it doesn't represeent
> dramatic new functionality for PostgreSQL.

For me the vacuum delay *does* represent a "dramatic new functionality"
and I was quite disappointed that the simple version did not make it into 7.4.

> I personally don't think Win32 is enough of a new feature either, but
> others disagree.

-----------
Hannu

Hannu Krosing wrote:
> > Sure, you can work around the lack of a Win32 port with Cygwin, and
> > maybe use replication in place of PITR, but the big question is are you
> > hitting a large precentage of users with an enhancement.
>
> I'm not sure that the initial version of PITR will be a good replacement
> for replication.
>
> > I am sure i
> > can get some "me too's" for your improvements, but it doesn't represeent
> > dramatic new functionality for PostgreSQL.
>
> For me the vacuum delay *does* represent a "dramatic new functionality"
> and I was quite disappointed that the simple version did not make it into 7.4.

Agreed, but you are a "me too", not a huge percentage of our userbase.

Basically, after 6-7 months of development, I want more than a vacuum
patch and a new cache replacement policy. I want something big, in
fact, several big things.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

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.

> 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

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Mon, 17 May 2004, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > On Sun, 16 May 2004, Bruce Momjian wrote:
> >
> > > I personally don't think Win32 is enough of a new feature either, but
> > > others disagree.
> >
> > Jan, correct me if I'm wrong ... Jan's point is that we have enough
> > already to warrant a beta on June 1st, even without Win32 ... Win32 (or
> > any of the other stuff, like PITR/tablespaces) would be icing on the cake
> > ...
>
> I disagree we have enough new features for a release, even with Win32.
> Our features are getting more complex and require more time to develop.

Not true ... you just have to fix your definition of what a feature is ...
a feature is an improvement to the system, whether it be new
functionality, or improved performance ... I consider the work Tom did on
the IN performance in 7.4 to have been a major feature, considering that
it made use of it *alot* more effective ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> > Agreed, but you are a "me too", not a huge percentage of our userbase.
>
> How do you know? Have you polled our complete userbase?
>
> > Basically, after 6-7 months of development, I want more than a vacuum
> > patch and a new cache replacement policy. I want something big, in
> > fact, several big things.
>
> Most likely won't happen, since what is considered big by you isn't
> necessarily what is considered big by someone else ... as Hannu, and I
> believe, Jan, have so far pointed out to you ...

I can't poll for everything. I make my own educated guesses.

For a small percentage, vacuum delay and ARC are significant. For a
larger percentage, PITR, Win32, tablespaces, and nested transactions are
significant. I don't need to take a poll for that, and a "me too"
doesn't change that fact.

To say otherwise is to pretend that all our enhancements are of equal
significance. Sure, for a given individual some are very important, but
in the aggregate things are pretty easy to guess.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Mon, May 17, 2004 at 01:53:19 -0300,
"Marc G. Fournier" <scrappy(at)postgresql(dot)org> wrote:
>
> Not true ... you just have to fix your definition of what a feature is ...
> a feature is an improvement to the system, whether it be new
> functionality, or improved performance ... I consider the work Tom did on
> the IN performance in 7.4 to have been a major feature, considering that
> it made use of it *alot* more effective ...

Personally, I found the 7.4 prebeta had a number of minor features that I
wanted. So far I haven't seen many things of particular interest to me
in 7.5. I haven't played with it yet, since there has been what appears
to be some pretty significant changes in some fundemental parts of 7.5
and as such there appears to be more risk than there was at this point in
7.4s release cycle.

Based on what I read about several of the "big" projects, it seems like
the difference between a June 1 beta and a July 1 beta is worth taking
the extra month to have a better chance at getting some of these projects in.

On Mon, 17 May 2004, Bruce Momjian wrote:

> Marc G. Fournier wrote:
> > > Agreed, but you are a "me too", not a huge percentage of our userbase.
> >
> > How do you know? Have you polled our complete userbase?
> >
> > > Basically, after 6-7 months of development, I want more than a vacuum
> > > patch and a new cache replacement policy. I want something big, in
> > > fact, several big things.
> >
> > Most likely won't happen, since what is considered big by you isn't
> > necessarily what is considered big by someone else ... as Hannu, and I
> > believe, Jan, have so far pointed out to you ...
>
> I can't poll for everything. I make my own educated guesses.

Based on what though?

All the clients that I deal with on a daily basis generally care about is
performance ... that is generally what they upgrade for ... so, my
'educated guess' based on real world users is that Win32, PITR and nested
transactions are not important ... tablespaces, I have one client that has
asked about something *similar* to it, but tablespaces, for him, doesn't
come close to what they would like to see ...

So, my 'educated guess' is different then yours is ... does that make
yours wrong? Nope ... just means we have different sample sets to work
with ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Mon, 17 May 2004, Bruce Momjian wrote:

> See my recent email. You are stating that all features are of equal
> significance. Basically, the important missing features are also the
> ones the require the most work to complete.

Agreed ... and the ones that require the most work to complete *will* span
multiple releases in between if they have to ... just because something
doesn't make it into 7.5 doesn't mean that the developer is going to drop
all their work and start from scratch hoping to make it into 7.6 ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Mon, 17 May 2004, Bruno Wolff III wrote:

> On Mon, May 17, 2004 at 01:53:19 -0300,
> "Marc G. Fournier" <scrappy(at)postgresql(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Mon, 17 May 2004, Bruce Momjian wrote:
>
>
>>Marc G. Fournier wrote:
>>
>>>>Agreed, but you are a "me too", not a huge percentage of our userbase.
>>>
>>>How do you know? Have you polled our complete userbase?
>>>
>>>
>>>>Basically, after 6-7 months of development, I want more than a vacuum
>>>>patch and a new cache replacement policy. I want something big, in
>>>>fact, several big things.
>>>
>>>Most likely won't happen, since what is considered big by you isn't
>>>necessarily what is considered big by someone else ... as Hannu, and I
>>>believe, Jan, have so far pointed out to you ...
>>
>>I can't poll for everything. I make my own educated guesses.
>
>
> Based on what though?
>
> All the clients that I deal with on a daily basis generally care about is
> performance ... that is generally what they upgrade for ... so, my
> 'educated guess' based on real world users is that Win32, PITR and nested
> transactions are not important ... tablespaces, I have one client that has
> asked about something *similar* to it, but tablespaces, for him, doesn't
> come close to what they would like to see ...
>
> So, my 'educated guess' is different then yours is ... does that make
> yours wrong? Nope ... just means we have different sample sets to work
> with ...
>

Interesting.
We have made COMPLETELY different experiences.

There is one question people ask me daily: "When can we have sychronous
replication and PITR?".
Performance is not a problem here. People are more interested in
stability and "enterprise" features such as those I have mentioned above.

I am still wondering about two things:
Somebody has posted a 2PC patch - I haven't seen too many comments
Somebody has posted sync multimaster replication (PgCluster) - nobody
has commented on that. Maybe I am the only one who has ever tried it ...

Most likely this is not very encourageing for the developers involved ...

Regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at

Hans-Jrgen Schnig 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)Yahoo(dot)com #

Christopher Kings-Lynne wrote:

>> Jan, correct me if I'm wrong ... Jan's point is that we have enough
>> already to warrant a beta on June 1st, even without Win32 ... Win32 (or
>> any of the other stuff, like PITR/tablespaces) would be icing on the cake
>> ...
>
> I think we're close enough on win32 to wait for it. It would look bad
> for us to miss inclusion of win32 two releases in a row...

Yes, unless this is "forever". Is there a clear commitment that Win32
will be done if we push from June to July?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Jan Wieck wrote:
> Christopher Kings-Lynne wrote:
>
> >> Jan, correct me if I'm wrong ... Jan's point is that we have enough
> >> already to warrant a beta on June 1st, even without Win32 ... Win32 (or
> >> any of the other stuff, like PITR/tablespaces) would be icing on the cake
> >> ...
> >
> > I think we're close enough on win32 to wait for it. It would look bad
> > for us to miss inclusion of win32 two releases in a row...
>
> Yes, unless this is "forever". Is there a clear commitment that Win32
> will be done if we push from June to July?

It is too late to think about pushing back another month. We had this
discussion already. June 1 is it.

I do think Win32 will make it, though.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)Yahoo(dot)com #

Jan Wieck wrote:
> > I am still wondering about two things:
> > Somebody has posted a 2PC patch - I haven't seen too many comments
> > Somebody has posted sync multimaster replication (PgCluster) - nobody
> > has commented on that. Maybe I am the only one who has ever tried it ...
>
> Do you really need someone "commenting" on query based replication? I
> get goosebumps from just thinking someone would voluntarily push all
> sequence- or timestamp-generation and other not strictly deterministic
> functionality into the application to be able to use such a "solution".
> This is exactly how people work around all the MySQL idiosyncrasies.
>
> >
> > Most likely this is not very encourageing for the developers involved ...
>
> Most hopefully this is very discouraging! Connection pools are a nice
> thing and I have used pgpool recently with great success, for pooling
> connections. But attempting to deliver multimaster replication as a
> byproduct of a connection pool isn't going to become an enterprise
> feature. And the more half-baked, half-functional and half-reliable
> replication attempts there are, the harder it will be to finally get a
> real solution being recognized.

Well, considering we offer _nothing_ for multi-master right now, I think
it is a valuable project.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Mon, 17 May 2004, Bruce Momjian wrote:
>
> > > Most hopefully this is very discouraging! Connection pools are a nice
> > > thing and I have used pgpool recently with great success, for pooling
> > > connections. But attempting to deliver multimaster replication as a
> > > byproduct of a connection pool isn't going to become an enterprise
> > > feature. And the more half-baked, half-functional and half-reliable
> > > replication attempts there are, the harder it will be to finally get a
> > > real solution being recognized.
> >
> > Well, considering we offer _nothing_ for multi-master right now, I think
> > it is a valuable project.
>
> Connection pooling is *not* multi master ... it doesn't even simulate
> multi-master ... multi-master, at least as far as I'm aware, means "no
> point of failure", and connection pooling creates a *single* point of
> failure ... the pgpool process dies, you've lost all connections to the
> database ...

I think people are confusing pgpool with pgcluster.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>
> Interesting.
> We have made COMPLETELY different experiences.
>
> There is one question people ask me daily: "When can we have sychronous
> replication and PITR?".
> Performance is not a problem here. People are more interested in
> stability and "enterprise" features such as those I have mentioned above.

I doubt that. Having deployed several 7.4 databases, the first customers ask
(of course not in technical speech, but in the meaning) when the problem with
checkpoint hogging system down is solved. This is a really serious issue,
especially when using drbd + ext3. The system will become really unresponsive
when checkpoint is running.

I heavily await 7.5 because of the background writer.

Mario Weilguni wrote:
>> Interesting. We have made COMPLETELY different experiences.
>>
>> There is one question people ask me daily: "When can we have
>> sychronous replication and PITR?". Performance is not a problem
>> here. People are more interested in stability and "enterprise"
>> features such as those I have mentioned above.
>
>
> I doubt that. Having deployed several 7.4 databases, the first
> customers ask (of course not in technical speech, but in the
> meaning) when the problem with checkpoint hogging system down is
> solved. This is a really serious issue, especially when using
> drbd + ext3. The system will become really unresponsive when
> checkpoint is running.
>
> I heavily await 7.5 because of the background writer.

This thread reminds me of Andrew Sullivan's signature:

The plural of anecdote is not data - Roger Brinner

Of course, once the sample size becomes sufficiently large, it does
become data. Has the advocacy group performed any polling in this
area that might shed some light as to what users and potential users
might want?

Mike Mascari

On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote:

> It is too late to think about pushing back another month. We had this
> discussion already. June 1 is it.
>

I think I have to reiterate: PITR won't make 1 June. (I will be away
travelling soon). This has been said a number of times.

This is all rather disheartening, having laid out a time plan months
back, noting some of this. Yes, I am working on it, and no, I'm not hand
waving, but I do take time off every million keystrokes or so.

Mid to late June is a realistic time for the completion of PITR, given
the additional features I am now working on and the time allocation I
can reasonably give this (which in many ways is already unreasonable).
My last publicly stated completion estimate was right to within a few
days (mid-April, stated in early March).

I'm a very task focused person and I strongly support the notion of
deadlines and freezes. It's just in this instance, 1 June seems to have
been plucked from the air - unless there are other pressures that others
can see better than I. What are they again?

7.5dev is loads better than 7.4, though that was true in February.
Having waited until now, why not wait for the features? If somebody
suggested that we do 7.5 now and then 8.0 with Win32 & PITR in
September, I'd think about that, but I'm worried that the next major
release is a long way out after this next one, not a few months. Beta is
gonna take ages anyhow.

Many people in the community are still using 7.3 or below. If the
releases come too frequently, running an initdb is just a pain,
especially with out a "big reason" to sell to the business folks as to
why they have to put up with the downtime of upgrading (or time spent on
clever plans). "Is it running? Yeh. So why upgrade?" for existing users,
and "Does it have feature XYZ? No, but they think next release. OK,
well, we'll wait for that and then trial it" for new adopters.

Shipping too early is a bad thing too. It's not clear to me why you
would ship in a hurry when the community has waited years to get some of
the features on the URGENT list. Honestly, how long has PITR been
brewing? And, who thinks that we'll get increased adoption without the
big ticket items? (Even if your opinion is that PITR isn't one of them).

I can't complete by 1 June. Think worse of me if you choose.

Best Regards, Simon Riggs

Hans-Jürgen Schönig wrote:
> Somebody has posted sync multimaster replication (PgCluster) - nobody
> has commented on that. Maybe I am the only one who has ever tried it ...

I didn't find it on pgFoundry, others place to look at it ?

Regards
Gaetano Mendola

Bruce Momjian wrote:
> Marc G. Fournier wrote:
>> On Mon, 17 May 2004, Bruce Momjian wrote:
>>
>> > > Most hopefully this is very discouraging! Connection pools are a nice
>> > > thing and I have used pgpool recently with great success, for pooling
>> > > connections. But attempting to deliver multimaster replication as a
>> > > byproduct of a connection pool isn't going to become an enterprise
>> > > feature. And the more half-baked, half-functional and half-reliable
>> > > replication attempts there are, the harder it will be to finally get a
>> > > real solution being recognized.
>> >
>> > Well, considering we offer _nothing_ for multi-master right now, I think
>> > it is a valuable project.
>>
>> Connection pooling is *not* multi master ... it doesn't even simulate
>> multi-master ... multi-master, at least as far as I'm aware, means "no
>> point of failure", and connection pooling creates a *single* point of
>> failure ... the pgpool process dies, you've lost all connections to the
>> database ...
>
> I think people are confusing pgpool with pgcluster.
>

And you wonder where that's coming from, eh? Tatsuo is advertising
pgpool as a synchronous replication system suitable for failover.
Quoting from the pgpool-1.0 README:

pgpool could be used as a replication server. This allows real-time
backuping of the database to avoid disk failures. pgpool sends
exactly same query to each PostgreSQL servers to accomplish
replication. So pgpool can be 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.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Simon Riggs wrote:
> On Mon, 2004-05-17 at 15:10, Bruce Momjian wrote:
>
>
>>It is too late to think about pushing back another month. We had this
>>discussion already. June 1 is it.
>>
>

Just to throw in my .02, plPerlNG won't be ready for testing until mid,
later June either. Then there is also plPHP which although we haven't
had any bug reports still needs some more peer review.

Also we would like to submit our ECPG which includes SET DESCRIPTOR and
error handling but that too needs more peer review.

It just seems, considering the current state of 7.4.2 (stable, just now
being deployed in production shops) that we should make a longer
development time for 7.5.

Personally, Win32, subtransactions and PITR are what we are after.
Second would be inclusion of plPHP and plPerlNG which are arguably the
most widely used languages to connect to PostgreSQL.

Sincerely,

Joshua D. Drake

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Mario Weilguni wrote:
>>Interesting.
>>We have made COMPLETELY different experiences.
>>
>>There is one question people ask me daily: "When can we have sychronous
>>replication and PITR?".
>>Performance is not a problem here. People are more interested in
>>stability and "enterprise" features such as those I have mentioned above.
>
>
> I doubt that. Having deployed several 7.4 databases, the first customers ask
> (of course not in technical speech, but in the meaning) when the problem with
> checkpoint hogging system down is solved. This is a really serious issue,
> especially when using drbd + ext3.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Well that seems to be part of the problem. ext3 does not scale well at
all under load. You should probably upgrade to a better FS (like XFS). I
am not saying that your point isn't valid (it is) but upgrading to a
better FS will help you.

Sincerely,

Joshua D. Drake

The system will become really unresponsive
> when checkpoint is running.
>
> I heavily await 7.5 because of the background writer.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)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(at)commandprompt(dot)com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

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(at)Yahoo(dot)com #

>
> plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
> ...

Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
replace plPerl, I was talking with Bruce and he seemed to think that (as
long as the code was good enough) that we could incorporate plPHP???

Sincerely,

Joshua D. Drake

>
>
> ----
> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy(at)hub(dot)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(at)commandprompt(dot)com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:

> I can't complete by 1 June. Think worse of me if you choose.

I'll mention another perspective as a user. I'm actually happier seeing a
relatively minor release come out just before the big changes hit. If 7.5 has
Windows, PITR, nested transactions, etc. especially if I see they went in just
before a feature freeze then I'm liable to wait before I suggest installing it
in production because it makes me fear the impact these major new features
will have on a system that's been running fine on 7.4.

Whereas if 7.5 comes out and is an incremental improvement over 7.4 with a
background writer, more knobs to control checkpoints and vacuum, better sorted
pg_dumps, etc, then I'm liable to install it right away. And I get to use
these features while the big changes settle.

From a user-perceptions point of view this is an even bigger factor when
people start bandying about 8.0. A LOT of sysadmins are going to hold off on
installing a release labelled 8.0 until they see 8.1 or 8.2. Sysadmins are an
awfully superstitious bunch and numerology is popular.

Moreover if PITR, the Windows port, nested transactions go into 7.6 or 8.0
right at the beginning of the development cycle and we have 3-4 months of
working with databases running with these features I strongly suspect that the
stability of the product will make a bigger long term impression than the
rapid pace of new features arriving.

So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
so, giving a nice reliable simple upgrade for people who just want a safe 7.x
series to upgrade to even after 8.0 comes out. PITR, nested transactions going
into the CVS tree sometime in June or July and being frozen as 8.0 towards the
end of the year.

--
greg

On Mon, 17 May 2004, Joshua D. Drake wrote:

>
> >
> > plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
> > ...
>
> Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
> replace plPerl, I was talking with Bruce and he seemed to think that (as
> long as the code was good enough) that we could incorporate plPHP???

That is the plan ... unless someone knows a reason why they can't be built
independently of the core? ecpg relies on the grammar files in core, but
as far as I knew (please correct me if I'm wrong) the pls only rely on
headers and libraries that get installed ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Greg Stark wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>
>>I can't complete by 1 June. Think worse of me if you choose.
>
...
> So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
> so, giving a nice reliable simple upgrade for people who just want a safe 7.x
> series to upgrade to even after 8.0 comes out. PITR, nested transactions going
> into the CVS tree sometime in June or July and being frozen as 8.0 towards the
> end of the year.

A quick google of "7.4 Win32 release" will reveal that the above was
precisely what was said about 7.4: it would be released to not hold
up important features like the IN optimization and a quick 7.5 would
have Win32 and PITR. It's almost as if a cron job reposts this
thread every 6 - 12 months. For those of us that are desirous of
PITR, it's a 6 month reposting that is becoming painful to read...

Mike Mascari

Mike Mascari <mascarm(at)mascari(dot)com> writes:

> Greg Stark wrote:
> > Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> >
> >>I can't complete by 1 June. Think worse of me if you choose.
> >
> ...
> > So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
> > so, giving a nice reliable simple upgrade for people who just want a safe 7.x
> > series to upgrade to even after 8.0 comes out. PITR, nested transactions going
> > into the CVS tree sometime in June or July and being frozen as 8.0 towards the
> > end of the year.
>
> A quick google of "7.4 Win32 release" will reveal that the above was precisely
> what was said about 7.4: it would be released to not hold up important features
> like the IN optimization and a quick 7.5 would have Win32 and PITR. It's almost
> as if a cron job reposts this thread every 6 - 12 months. For those of us that
> are desirous of PITR, it's a 6 month reposting that is becoming painful to
> read...

I'm not sure what your point is though. It's not like people with my attitude
made the people writing code take any longer. In fact had we held off 7.4 for
any of these features it would have been a disaster.

Incidentally, I'm not suggesting rushing 7.6/8.0 out the door. I'm imagining a
regular release cycle. My comments are more geared to the idea that having
PITR, Nested Transactions, etc hit the tree early in the development cycle
would be smoother than having them hit right at the end of the development
cycle.

Think of all the added bells and whistles PITR will be able to grow over the
course of a whole release cycle. Instead of having a barebones "see it works"
implementation we'll have a really polished system with lots of optional but
appreciated features. Maybe better integration in third-party backup tools,
maybe even standby databases or replication based on it.

--
greg

On Mon, 17 May 2004, Mike Mascari wrote:

> Greg Stark wrote:
> > Simon Riggs <simon(at)2ndquadrant(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Mon, 17 May 2004, Joshua D. Drake wrote:
>
>> Personally, Win32, subtransactions and PITR are what we are after.
>> Second would be inclusion of plPHP and plPerlNG which are arguably the
>> most widely used languages to connect to PostgreSQL.
>
> plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
> ...

When are you going to pull PL/pgSQL, PL/python and PL/Tcl?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Marc G. Fournier wrote:

> On Mon, 17 May 2004, Joshua D. Drake wrote:
>
>>
>> >
>> > plPHP and plPerlNG both belong on pgfoundry, not in the core distribution
>> > ...
>>
>> Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
>> replace plPerl, I was talking with Bruce and he seemed to think that (as
>> long as the code was good enough) that we could incorporate plPHP???
>
> That is the plan ... unless someone knows a reason why they can't be built
> independently of the core? ecpg relies on the grammar files in core, but
> as far as I knew (please correct me if I'm wrong) the pls only rely on
> headers and libraries that get installed ...

They are not as independant as one might think. The core support for set
returning functions is required before a PL can do it. Same was with
cursors and same will be with subtransactions being the base for
exception handling. People have been struggling with unloadable shared
objects from another version due to elog changes, I can't imagine what
kind of support horror we're creating with this now.

The much I am for pulling stuff that does not belong into core, doing it
just for the fun of cleaning up or trimming doesn't do. One of the major
functions of CVS is that one can tag collections of revisions that
together build a release, a "known to be working snapshot of file
revisions". If we completely lose the ability to tell what version of
what PL, client interface or extension works with what version of the
backend, we're losing some important detail here.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

> Bruce Momjian wrote:
> > Marc G. Fournier wrote:
> >> On Mon, 17 May 2004, Bruce Momjian wrote:
> >>
> >> > > Most hopefully this is very discouraging! Connection pools are a nice
> >> > > thing and I have used pgpool recently with great success, for pooling
> >> > > connections. But attempting to deliver multimaster replication as a
> >> > > byproduct of a connection pool isn't going to become an enterprise
> >> > > feature. And the more half-baked, half-functional and half-reliable
> >> > > replication attempts there are, the harder it will be to finally get a
> >> > > real solution being recognized.
> >> >
> >> > Well, considering we offer _nothing_ for multi-master right now, I think
> >> > it is a valuable project.
> >>
> >> Connection pooling is *not* multi master ... it doesn't even simulate
> >> multi-master ... multi-master, at least as far as I'm aware, means "no
> >> point of failure", and connection pooling creates a *single* point of
> >> failure ... the pgpool process dies, you've lost all connections to the
> >> database ...

I think multi-master does nothing with
free-from-single-point-of-failure. A multi-master replication system
could have its own single point of failure (for example, some systems
have single "coordinate server"). On the other hand single-master
replication system could avoid single point of failure using some
external mechanism (for example UltraMonkey).

> > I think people are confusing pgpool with pgcluster.
> >
>
> And you wonder where that's coming from, eh? Tatsuo is advertising
> pgpool as a synchronous replication system suitable for failover.
> Quoting from the pgpool-1.0 README:

Please do not use the word "failover" for pgpool relication
functionality. "Failover" means it could continue replication
operation with alternative database. pgpool does not do that in
replication mode. Instead it disconnect the failed DB and continues
operation with healthy DB (with no replication, of course). That's why
I use the word "degeneration" in pgpool's replication mode.

> pgpool could be used as a replication server. This allows real-time
> backuping of the database to avoid disk failures. pgpool sends
> exactly same query to each PostgreSQL servers to accomplish
> replication. So pgpool can be regarded as a "synchronous
> replication server".
>
> Don't get me wrong, as said pgpool works great for the purpose I tested,
> the pooling. But statements like that are causing the confusion here.

Could you tell me why above is confusing? If it's really confusing,
I'm glad to enhance it. Or are you saying pgpool should not be regrard
as having "replicaton facility"?

Or you are saying that pgpool is too similar to PGCluster?

PGCluster is a multi-master/multi-slave/sync relication system. pgpool
is a single-master/single-slave/sync replication. There's a clear
distinction. single vs. multi-master is a BIG difference and I have
never stated that pgpool is a multi-master replication system.

BTW, the reason why I developed pgpool with replication functionality
is that there's no single perfect replication solution in the
world. Here are my comments for officially released replicatin systems
(from my own point of view, of course):

1) DBMirror:
good: simple and easy to use.
bad: can not handle too much traffic. cannot replicate large objects.

2) PGCluster:
good: can handle failover and recovery. SELECT load balancing is
really nice.

bad: requries many PCs. update performance is not good. cannot
replicate large objects.

3) pgpool:
good: simple and easy to use. can replicate large objects. update
performance is not too bad.
bad: no load balancing, no failover.

I'm interested in if Slony-I solves all these "bad". I will try it when
I have spare time.
--
Tatsuo Ishii

> The much I am for pulling stuff that does not belong into core, doing
> it just for the fun of cleaning up or trimming doesn't do. One of the
> major functions of CVS is that one can tag collections of revisions
> that together build a release, a "known to be working snapshot of file
> revisions". If we completely lose the ability to tell what version of
> what PL, client interface or extension works with what version of the
> backend, we're losing some important detail here.
>
Also, one of the best features of PostgreSQL is that you can, at will
write a procedure in just about anything... It seems that keeping at least
the most popular pl implementations would be an important step.

]

>
> Jan
>

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

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

J

--
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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Joshua D. Drake wrote:
> Just to throw in my .02, plPerlNG won't be ready for testing until mid,
> later June either. Then there is also plPHP which although we haven't
> had any bug reports still needs some more peer review.
>
> Also we would like to submit our ECPG which includes SET DESCRIPTOR and
> error handling but that too needs more peer review.

I assume your ecpg will be a patch to the existing ecpg rather than a
new verion, right?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> He is waiting for nested transactions to be committed so he can merge
> his work in.
>
>
>>Somebody has posted sync multimaster replication (PgCluster) - nobody
>>has commented on that. Maybe I am the only one who has ever tried it ...
>
>
> I think it should be on gborg.

You mean pgFoundry :)

Chris

Marc G. Fournier wrote:
> On Mon, 17 May 2004, Mike Mascari wrote:
>
>>A quick google of "7.4 Win32 release" will reveal that the above was
>>precisely what was said about 7.4: it would be released to not hold
>>up important features like the IN optimization and a quick 7.5 would
>>have Win32 and PITR. It's almost as if a cron job reposts this
>>thread every 6 - 12 months. For those of us that are desirous of
>>PITR, it's a 6 month reposting that is becoming painful to read...
>
> k, let's think this through ... 7.4 was released, what, 6 months ago? And
> 6 months later, PITR still isn't ready? Is there some logic here that if
> 7.4 wasn't released, PITR would have been done any sooner?

Not being the author, I don't know. And in the case of PITR, the
pre-7.4 author is different than the post-7.4 author. However, if I
was personally responsible for holding up the release of a project
due to a feature that I had vowed to complete, I would feel morally
compelled to get it done. If I had then asked for, and was granted,
an extra 15-30 days I would feel even more personally responsible
and under greater pressure.

If, however, the project made the release without waiting, I would
feel simultaneously relieved and possibly a little bitter. Possibly
a little bitter in that either what I was working on wasn't
perceived as sufficiently valuable to hold up a release for 15-30
days, or that my word regarding the completion status was
insufficient for the project to trust me. Let me reiterate the words
"possibly" and "little." But in open source projects, a developer
willing to contribute hundreds, possibly thousands of hours of his
own time is particularly invaluable.

I can tell you that, in economic models that have studied human
behavior with respect to unemployment insurance, for example, the
re-employment rates are clustered at the tails: when someone is
first unemployed and when the insurance is about to expire. It's an
inappropriate analogy because the project lives on from release to
release, instead of having a drop-dead date at which point no future
changes would be made ad infinitum, but it paints a useful picture.
I'm willing to bet that CVS commit rates mirror the above behavior.

Unlike unemployment benefits, releasing the software without the
feature essentially just extends the development period another 6
months, the work will intensify at the new perceived tails, and the
process repeated. There are probably econometric papers that model
the software development release cycle that could give quantitative
arguments. I'm not arguing I'm right and your wrong, btw. I'm just
pointing out some of the possibilities. In fact, for one developer
it might be the "code production maximizing condition" to give them
another 6 months and for another, creating the pressure associated
with a 15-30 day extension where the world is standing still
awaiting their patch...

Mike Mascari

On Mon, 17 May 2004, 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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

On Mon, 17 May 2004, Bruce Momjian wrote:

> Server-side languages are tied into the backend even closer than the
> user data types. They are best in the core distribution. We didn't put
> plR in core because it had a conflicting license.

So, they can live on their own, which is a good thing to know ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:
> On Mon, 17 May 2004, Joshua D. Drake wrote:
>
> >
> > >
> > >I assume your ecpg will be a patch to the existing ecpg rather than a
> > >new verion, right?
> > >
> > >
> > >
> > Yes it is a patch against 7.4.2
>
> Will you have one against -HEAD? I believe there have been changes since
> 7.5 was branched, no? Or have they been mostly cosmetic/docs?

Josh just sent me the patch and it looks good. I encouraged him to send
it over to Michael Meskes, and soon, especially if he wants it in 7.5.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>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(at)hub(dot)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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Bruce Momjian said:
> Marc G. Fournier wrote:
>> On Mon, 17 May 2004, Joshua D. Drake wrote:
>>
>> >
>> > >
>> > > plPHP and plPerlNG both belong on pgfoundry, not in the core
>> > > distribution ...
>> >
>> > Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed
>> > to replace plPerl, I was talking with Bruce and he seemed to think
>> > that (as long as the code was good enough) that we could incorporate
>> > plPHP???
>>
>> That is the plan ... unless someone knows a reason why they can't be
>> built independently of the core? ecpg relies on the grammar files in
>> core, but as far as I knew (please correct me if I'm wrong) the pls
>> only rely on headers and libraries that get installed ...
>
> Server-side languages are tied into the backend even closer than the
> user data types. They are best in the core distribution. We didn't
> put plR in core because it had a conflicting license.
>

I would never have created the plperlNG project on pgfoundry if I had
thought it meant divorcing plperl from the core.

pgfoundry in my mind can be a home for projects that will eventually fold
into the core, as well as things that will always remain separate.

I agree with Bruce about the place of server-side PLs.

cheers

andrew

Marc G. Fournier wrote:
> > A quick google of "7.4 Win32 release" will reveal that the above was
> > precisely what was said about 7.4: it would be released to not hold
> > up important features like the IN optimization and a quick 7.5 would
> > have Win32 and PITR. It's almost as if a cron job reposts this
> > thread every 6 - 12 months. For those of us that are desirous of
> > PITR, it's a 6 month reposting that is becoming painful to read...
>
> k, let's think this through ... 7.4 was released, what, 6 months ago? And
> 6 months later, PITR still isn't ready? Is there some logic here that if
> 7.4 wasn't released, PITR would have been done any sooner?

Even though I was for a later feature freeze, Marc argument is
powerful.

There was talk that Win32 and PITR would be available right after 7.5
started development, and they weren't. Instead it took several months
for Patrick and Tom to get JR's PITR/WAL patch into CVS, and then
another month or two for someone to appear and do the work of archiving
the files, then after discussion of implementation issues, it now needs
even more work. Win32 has been on a steady course thanks to Claudio and
Magnus --- without them we would be nowhere near finished. Nested
transactions were started in April and tablespaces in February, both
funded by Fujitsu.

Basically, maybe Marc is right that these features have to span multiple
releases. Win32 spanned two releases (some of it was in 7.4). PITR WAL
was initially done by JR just before 7.3 feature freeze, I think, but it
took all this time to get this far.

Basically, my big concern is "incremental improvement" releases, which I
feel describe our past few releases. Yes, I said it. I see items
listed above as critical to allowing PostgreSQL to move into more
significant roles in enterprises, and I am frustrated that it is taking
so long to happen.

What can be done? Well, money from Fujitsu and other companies
(Afilias/Sloney, Command Prompt/ecpg-plPHP), is allowing us to hit some
of these bigger items, so hopefully that will move us forward in these
complex areas. I am not sure what could have been done to push some of
these projects along faster. I am happy Win32 had a steady pace of
improvement, but even now we are finishing up to the wire rather than
having it done months ago, but in hindsight, I am not sure what we could
have done differently.

So, yea, I am frustrated. I know these features are hard and complex,
but I want them for PostgreSQL, and I want them as soon as possible. I
guess what really bugs me is that we are so close to having these few
remaining big features, and because they are so complex, they are taking
a lot longer to arrive than previous features, and sometimes see a year
pass without progress on some items, and that bugs me.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Mon, May 17, 2004 at 17:06:18 -0400,
Greg Stark <gsstark(at)mit(dot)edu> wrote:
>
> I'll mention another perspective as a user. I'm actually happier seeing a
> relatively minor release come out just before the big changes hit. If 7.5 has
> Windows, PITR, nested transactions, etc. especially if I see they went in just
> before a feature freeze then I'm liable to wait before I suggest installing it
> in production because it makes me fear the impact these major new features
> will have on a system that's been running fine on 7.4.

7.5 has already had some significant changes made in how writes are done
to disk. If I had very valuable data to protect I would already consider
7.5 a risky upgrade (in comparison to the 7.3 to 7.4 upgrade).

If this is your situation, going to 7.4.3 and sticking with it for a while
waiting to see how 7.5 does, may be a good idea.

>So, yea, I am frustrated. I know these features are hard and complex,
>but I want them for PostgreSQL, and I want them as soon as possible. I
>guess what really bugs me is that we are so close to having these few
>remaining big features, and because they are so complex, they are taking
>a lot longer to arrive than previous features, and sometimes see a year
>pass without progress on some items, and that bugs me.
>
>
>
So why do we wait for some of these features? The bgwriter is done
right? Why don't we backport to
7.4.x and release with 7.4.3? What about the vacuum stuff Jan was doing?

I guess what I am saying is, what features are in HEAD that can be
backported to 7.4.x without the
requiring of an initdb?

Yes it would be breaking from the tradition of very little feature
releases in incrementals but then again
maybe that would be a good thing...

Sincerely,

Joshua D. Drkae

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

On Mon, 17 May 2004, Joshua D. Drake wrote:

>
> >So, yea, I am frustrated. I know these features are hard and complex,
> >but I want them for PostgreSQL, and I want them as soon as possible. I
> >guess what really bugs me is that we are so close to having these few
> >remaining big features, and because they are so complex, they are taking
> >a lot longer to arrive than previous features, and sometimes see a year
> >pass without progress on some items, and that bugs me.
> >
> >
> >

> So why do we wait for some of these features? The bgwriter is done
> right? Why don't we backport to 7.4.x and release with 7.4.3? What about
> the vacuum stuff Jan was doing?
>
> I guess what I am saying is, what features are in HEAD that can be
> backported to 7.4.x without the requiring of an initdb?
>
> Yes it would be breaking from the tradition of very little feature
> releases in incrementals but then again maybe that would be a good
> thing...

This has been put forward by me a couple of times in the past, and, to a
small extent, I do agree with the arguments against it ... namely, the
backporting, testing and release cycles that we'd have to adopt would
detract from forward development ...

As soon as we get to backporting features, then we have to get into
feature freezes on the "stable" branch, beta periods of testing leading to
a release, etc ...

I'd almost say that time would be better spent on coming up with an
effective upgrade method so that upgrading to new releases is easier ...

Please note that I'm not against the backporting, but do understand the
arguments against it in terms of time and manpower ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

> Not being the author, I don't know. And in the case of PITR, the pre-7.4
> author is different than the post-7.4 author. However, if I was
> personally responsible for holding up the release of a project due to a
> feature that I had vowed to complete, I would feel morally compelled to
> get it done. If I had then asked for, and was granted, an extra 15-30
> days I would feel even more personally responsible and under greater
> pressure.
>
> If, however, the project made the release without waiting, I would feel
> simultaneously relieved and possibly a little bitter. Possibly a little
> bitter in that either what I was working on wasn't perceived as
> sufficiently valuable to hold up a release for 15-30 days, or that my
> word regarding the completion status was insufficient for the project to
> trust me. Let me reiterate the words "possibly" and "little." But in
> open source projects, a developer willing to contribute hundreds,
> possibly thousands of hours of his own time is particularly invaluable.
>
> I can tell you that, in economic models that have studied human behavior
> with respect to unemployment insurance, for example, the re-employment
> rates are clustered at the tails: when someone is first unemployed and
> when the insurance is about to expire. It's an inappropriate analogy
> because the project lives on from release to release, instead of having
> a drop-dead date at which point no future changes would be made ad
> infinitum, but it paints a useful picture. I'm willing to bet that CVS
> commit rates mirror the above behavior.
>
> Unlike unemployment benefits, releasing the software without the feature
> essentially just extends the development period another 6 months, the
> work will intensify at the new perceived tails, and the process
> repeated. There are probably econometric papers that model the software
> development release cycle that could give quantitative arguments. I'm
> not arguing I'm right and your wrong, btw. I'm just pointing out some of
> the possibilities. In fact, for one developer it might be the "code
> production maximizing condition" to give them another 6 months and for
> another, creating the pressure associated with a 15-30 day extension
> where the world is standing still awaiting their patch...
>
> Mike Mascari

Yesterday I have issued a posting which had to do with "motivation".
This is Open Source - there is no boss which tells somebody to finish
something. Therefore we must MOTIVATE people.
Has anybody read Sim Riggs posting earlier in the thread.
There is one paragraph which makes my alarm bells ring VERY LOUD:

"This is all rather disheartening, having laid out a time plan months
back, noting some of this. Yes, I am working on it, and no, I'm not hand
waving, but I do take time off every million keystrokes or so."

If somebody who has done a GREAT JOB is disheartened by the way his work
is treated it is really time to start thinking ...

From my very personal point of view Mike absolutely right; why not give
it a try. I guess Simon and Alvaro deserve some more time and we should
give those guys a limited time frame to finish their work.

Recall, it's all about motivation ...

Regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/233 90 75
www.cybertec.at, www.postgresql.at, kernel.cybertec.at

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

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

>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(at)copelandconsulting(dot)net
Copeland Computer Consulting
940.206.8004

Am Tuesday 18 May 2004 07:40 schrieb Greg Copeland:
> >From the FAQ (http://www.drbd.org/316.html):
>
> Q: Can XFS be used with DRBD?
>
>
> A: XFS uses dynamic block size, thus DRBD 0.7 or later is needed.
>
> Hope we're talking about the same project. ;)

Hmmm, interesting. But I did not find 0.7 on the history page http://www.drbd.org/releases.html
maybe it's not release status yet - thus no option for now.

Regards,
Mario Weilguni

Marc G. Fournier wrote:
> That is the plan ... unless someone knows a reason why they can't be
> built independently of the core?

How about this one: Everything we have moved from the core to gborg so
far has been a miserable failure. The code is no longer maintained, or
maintained by three different competing groups, the documentation has
disappeared, the portability is no longer taken care of, and only the
bravest souls even dare look at the stuff. I think before you move
anything more, you need to have a strong, convincing community on the
receiving side rather than just kicking things out and hoping someone
will pick it up. Just because it can be built separately doesn't mean
everything needs to be.

Joshua D. Drake wrote:
> Uhhh?? Are you ripping out all core pls then? plPerlNG is supposed to
> replace plPerl, I was talking with Bruce and he seemed to think that
> (as long as the code was good enough) that we could incorporate
> plPHP???

One reason against including plPHP in the core would be that it would
create a circular build dependency between the packages postgresql and
php. I think we should rather avoid that.

> How about this one: Everything we have moved from the core to gborg so
> far has been a miserable failure. The code is no longer maintained, or
> maintained by three different competing groups, the documentation has
> disappeared, the portability is no longer taken care of, and only the
> bravest souls even dare look at the stuff. I think before you move
> anything more, you need to have a strong, convincing community on the
> receiving side rather than just kicking things out and hoping someone
> will pick it up. Just because it can be built separately doesn't mean
> everything needs to be.

Above looks quite true for me too.
--
Tatsuo Ishii

Peter Eisentraut wrote:
> How about this one: Everything we have moved from the core to gborg so
> far has been a miserable failure. The code is no longer maintained, or
> maintained by three different competing groups, the documentation has
> disappeared, the portability is no longer taken care of, and only the
> bravest souls even dare look at the stuff. I think before you move
> anything more, you need to have a strong, convincing community on the
> receiving side rather than just kicking things out and hoping someone
> will pick it up. Just because it can be built separately doesn't mean
> everything needs to be.

I guess the key thing is that pgFoundry shouldn't be a community
distinct from the core. The same community standards need to apply
on both sides of the fence.

What has happened here echoes the experiences of the PHP project
very closely. PHP, too, thought that the core was getting too big
for efficient release coordination, and started moving extensions
to PECL, an extension library bolted on the side of PEAR.

Trouble is, nobody wants to be forced into the ghetto. The only way
to make pgFoundry work is to minimize the downside of living there.
Consider these:

- Don't move just "inessential" projects. Move absolutely
essential projects to push end-user and developer adoption.

- Have a tier of "official" projects that are actively endorsed
by and within the core distribution. Don't be afraid to pick 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 messages to
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 only exists 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 makefiles included in
the core that'd download and compile the latest compatible version.
Components as important as JDBC and some of the procedural
languages could be distributed this way.

mk

Marko Karppinen wrote:
>
> I guess the key thing is that pgFoundry shouldn't be a community
> distinct from the core. The same community standards need to apply
> on both sides of the fence.
[snip]

Thanks Marko, you just wrote exactly what I was concerned about with
"features" rather than "applications" being in pgfoundry.

The only thing I'd add is that we need to separate development from
delivery. The important thing as an end-user is not where the CVS is
kept or how things are kept in-sync but:
1. Can I get hold of it easily?
2. Is it mentioned in the manual?
3. Do I know what versions of PG/other it needs?

pl/PHP etc might not need to be in the core CVS or tar.gz, but probably
do need to be in a pl/ or plugins/ directory on the main site. If it
takes a week or two (after release) for the various plugins to appear,
that's fine - no-one upgrades a production system on day 1 anyway.

Perhaps this is the best way to look at it - when the .rpm's/.deb's are
put together what does the community want in them?

--
Richard Huxton
Archonet Ltd

On Mon, 2004-05-17 at 19:39, Marc G. Fournier wrote:
> On Mon, 17 May 2004, Mike Mascari wrote:
> > Greg Stark wrote:
> > > Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > >
> > >>I can't complete by 1 June. Think worse of me if you choose.
> > >
> > ...
> > > So in my perfect world I picture 7.5 freezing June 1 and releasing in July or
> > > so, giving a nice reliable simple upgrade for people who just want a safe 7.x
> > > series to upgrade to even after 8.0 comes out. PITR, nested transactions going
> > > into the CVS tree sometime in June or July and being frozen as 8.0 towards the
> > > end of the year.
> >
> > A quick google of "7.4 Win32 release" will reveal that the above was
> > precisely what was said about 7.4: it would be released to not hold
> > up important features like the IN optimization and a quick 7.5 would
> > have Win32 and PITR. It's almost as if a cron job reposts this
> > thread every 6 - 12 months. For those of us that are desirous of
> > PITR, it's a 6 month reposting that is becoming painful to read...
>
> k, let's think this through ... 7.4 was released, what, 6 months ago? And
> 6 months later, PITR still isn't ready? Is there some logic here that if
> 7.4 wasn't released, PITR would have been done any sooner?
>

Potentially yes. One thing all of the developers have said they want is
more feedback from some of the more expert developers, but if we go into
feature freeze then the focus of folks like Tom and Bruce will be on
completing release, not on helping out with these new features. We had
the original patch for PITR before 7.4 went into beta IIRC, but it then
had to sit through a lengthy beta process before Tom could do some final
code review and get things committed.

Just like Bruce has often asked the community how they feel about him
balancing his time between things like speaking engagements and patch
applications, core developers have a limited amount of time they can
spend on any given development effort. If I had to pick (If I got to
pick?), I would rather see Bruce/Tom/Jan working on helping these guys
finish PITR/WIN32/Tablespaces/etc... than working on closing the 7.5
branch.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

>a release, etc ...
>
>I'd almost say that time would be better spent on coming up with an
>effective upgrade method so that upgrading to new releases is easier ...
>
>Please note that I'm not against the backporting, but do understand the
>arguments against it in terms of time and manpower ...
>
>
I believe they are valid arguments too and if we were to do it we would
definately need to be
selective about "which" features get back ported but forward movement
can be in the present
tree as well.

Joshua D. Drake

>----
>Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
>Email: scrappy(at)hub(dot)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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Peter Eisentraut wrote:

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

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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

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(at)crankycanuck(dot)ca

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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

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?
>
>
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
;). 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.

Sincerely,

Joshua D. Drake

>----
>Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
>Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
>

--
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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073