Re: [HACKERS] Not 7.5, but 8.0 ?

Folks,

Of course, while I was editing press releases at 2am, I started thinking about
our next version. It seems certain that the next release, in 6-9 months,
will have at a minimum the Windows port and ARC, if not Slony-I as well.

Given all that, don't people think it's time to jump to 8.0? Seems like
even 7.4 is hardly recognizable as the same database as 7.0.

I'm posting this to both Advocacy and Hackers because I think that some people
will have rather different points of view on the issue. But I wanted to
start a discussion early this time. No flamewars, please! We all want
PostgreSQL to be the best possible database.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> It seems certain that the next release, in 6-9 months, will have at
> a minimum the Windows port and ARC, if not Slony-I as well.
>
> Given all that, don't people think it's time to jump to 8.0?

It seems a little premature to speculate on what features may or may
not be present in 6 to 9 months time. Why make this decision now, when
we don't even know what will be in the next release, rather than at
the end of the development cycle?

-Neil

Josh Berkus writes:

> Given all that, don't people think it's time to jump to 8.0?

As has been said before, many people think that a Windows port is the
least interesting feature ever to happen to PostgreSQL, so you're going to
have to come up with better reasons. Also note that most major number
changes in the past weren't because the features were cool, but because
the project has moved to a new phase. I don't see any such move
happening.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter,

> As has been said before, many people think that a Windows port is the
> least interesting feature ever to happen to PostgreSQL, so you're going to
> have to come up with better reasons.

Yeah, I'm more interested in ARC and replication ... and the SQL
standardization that just went into 7.4.

> Also note that most major number
> changes in the past weren't because the features were cool, but because
> the project has moved to a new phase. I don't see any such move
> happening.

Now that is interesting. I missed that. Can you explain how that worked
with 7.0?

--
Josh Berkus
Aglio Database Solutions
San Francisco

Peter Eisentraut wrote:

> As has been said before, many people think that a Windows port is the
> least interesting feature ever to happen to PostgreSQL, so you're going to
> have to come up with better reasons. Also note that most major number
> changes in the past weren't because the features were cool, but because
> the project has moved to a new phase. I don't see any such move
> happening.

What happens if Postgres hits 7.9 but still hasn't reached the next
phase? :)

Hello,

If Win32 actually makes it into 7.5 then yes I believe 8.0 would be
appropriate.

Sincerely,

Joshua D. Drake

On Mon, 17 Nov 2003, Josh Berkus wrote:

> Folks,
>
> Of course, while I was editing press releases at 2am, I started thinking about
> our next version. It seems certain that the next release, in 6-9 months,
> will have at a minimum the Windows port and ARC, if not Slony-I as well.
>
> Given all that, don't people think it's time to jump to 8.0? Seems like
> even 7.4 is hardly recognizable as the same database as 7.0.
>
> I'm posting this to both Advocacy and Hackers because I think that some people
> will have rather different points of view on the issue. But I wanted to
> start a discussion early this time. No flamewars, please! We all want
> PostgreSQL to be the best possible database.
>
>

--
Co-Founder
Command Prompt, Inc.
The wheel's spinning but the hamster's dead

> As has been said before, many people think that a Windows port is the
> least interesting feature ever to happen to PostgreSQL, so you're going to

Yes but these are people running Unix/Linux/BSD not Windows ;)

> have to come up with better reasons. Also note that most major number
> changes in the past weren't because the features were cool, but because
> the project has moved to a new phase. I don't see any such move
> happening.
>
>

--
Co-Founder
Command Prompt, Inc.
The wheel's spinning but the hamster's dead

On Mon, 17 Nov 2003, Josh Berkus wrote:

> Given all that, don't people think it's time to jump to 8.0? Seems like
> even 7.4 is hardly recognizable as the same database as 7.0.

Discussion like this tends to be more for just before beta, once we have
an idea what actually made it in :) You be putting the cart before the
horse, eh?

Joshua D. Drake wrote:

> Hello,
>
> If Win32 actually makes it into 7.5 then yes I believe 8.0 would be
> appropriate.

It might be interesting to track Oracle's version number viz. its
feature list. IOW, a PostgreSQL 8.0 database would be feature
equivalent to an Oracle 8.0 database. That would mean:

1) PITR
2) Distributed Tx
3) Replication
4) Nested Tx
5) PL/SQL Exception Handling

IMHO, a major version number jump should at least match the delta in
features one finds in the commercial segment with their major version
number bumps. Otherwise, I suspect it would be viewed as window
dressing...

Could be wrong, though...

Mike Mascari
mascarm(at)mascari(dot)com

Oops! josh(at)agliodbs(dot)com (Josh Berkus) was seen spray-painting on a wall:
> Given all that, don't people think it's time to jump to 8.0? Seems
> like even 7.4 is hardly recognizable as the same database as 7.0.

If wishes were fishes... Shouldn't we see what interesting features
actually _do_ make it in?

If Win32 support does get ready, and we get recursive queries (I'll
point out different TODO items :-)) and Slony-1, PITR, and cache
improvements make it in, then perhaps it's time to call it 8.0. A
"cvs update -Pd" doesn't get me that yet, so it seems early.

I'd _almost_ buy the story that 7.4 should have been called 8.0,
although that _didn't_ happen because it 'just missed' PITR and Win32.

The amusing approach would be to jump straight to 8.1 :-).
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www.ntlug.org/~cbbrowne/postgresql.html
..you could spend *all day* customizing the title bar. Believe me. I
speak from experience." -- Matt Welsh

Josh Berkus wrote:
> > Also note that most major number
> > changes in the past weren't because the features were cool, but because
> > the project has moved to a new phase. I don't see any such move
> > happening.
>
> Now that is interesting. I missed that. Can you explain how that worked
> with 7.0?

We stopped crashing in 7.0, or was it 6.5 --- that was our milestone, I
think. :-)

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

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

> 1) PITR
> 2) Distributed Tx
> 3) Replication
> 4) Nested Tx
> 5) PL/SQL Exception Handling

Of these PITR seems *by far* the most important. It makes the difference
between an enterprise-class database capable of running 24x7 with disaster
recovery plans, and a lesser beast that needs to be shut down for cold backups
periodically.

Features like Nested Transactions and Exception Handling are "would be nice"
features. Especially for pre-existing code-bases. But for new projects they're
not things that make the difference between measuring up and not.

Besides, Oracle 8 had Replication the way Mysql has transactions... It a
recently bolted-on addition that only worked in limited cases until a few
rewrites later.

Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of
OSes already. What's so exciting about one more? Even if it is a
pathologically hard OS to port to. Just because it was hard doesn't mean it's
useful.

--
greg

> Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of
> OSes already. What's so exciting about one more? Even if it is a
> pathologically hard OS to port to. Just because it was hard doesn't mean it's
> useful.

I don't call porting Postgres to run well on something like 40% of the
world's servers (or whatever it is) "just another port".

It could conveivably double Postgres's target audience, could attract
heaps of new users, new developers, new companies and put us in a better
position to compete with MySQL.

I think it's actually a necessary port to keep the project alive in the
long term.

Chris

Christopher Kings-Lynne wrote:

>> Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on
>> dozens of
>> OSes already. What's so exciting about one more? Even if it is a
>> pathologically hard OS to port to. Just because it was hard doesn't
>> mean it's
>> useful.
>
> I don't call porting Postgres to run well on something like 40% of the
> world's servers (or whatever it is) "just another port".
>
> It could conveivably double Postgres's target audience, could attract
> heaps of new users, new developers, new companies and put us in a
> better position to compete with MySQL.
>
> I think it's actually a necessary port to keep the project alive in
> the long term.

Absolutely! In addition, even if you don't consider win32 a platform to
run production databases on, the win32 port will help developers who
work from windows boxes, which is the certainly the most widely used
desktop environment. My former company would have loved the win32 port
for exactly this reason, even though most of our servers were FreeBSD /
Linux.

Matthew T. O'Connor writes:

> Absolutely! In addition, even if you don't consider win32 a platform to
> run production databases on, the win32 port will help developers who
> work from windows boxes, which is the certainly the most widely used
> desktop environment.

At the risk of stating the obvious: Cygwin is your friend in exactly this
case.

--
Peter Eisentraut peter_e(at)gmx(dot)net

, 18.11.2003, 00:43, William Yu :

> What happens if Postgres hits 7.9 but still hasn't reached the next
> phase? :)

Easy - 7.10.

--
Markus Bertheau <twanger(at)bluetwanger(dot)de>

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:

> > I don't call porting Postgres to run well on something like 40% of the
> > world's servers (or whatever it is) "just another port".
> >
> > It could conveivably double Postgres's target audience, could attract heaps
> > of new users, new developers, new companies and put us in a better position
> > to compete with MySQL.

That's a misleading extrapolation. If people wanted to run an open source
database they could just as easily run a Solaris, Linux, or BSD server to run
it on anyways. I assure you 40% of the worlds servers will not switch from
MSSQL to Postgres the day the win32 port comes out...

The reality is it just doesn't happen that way. Postgres isn't the first major
unixy software to get ported to windows. Emacs, Gcc, Mozilla, Gimp, even X all
have windows ports. And they're not dead ports either, they have significant
user-bases. But they don't make much of a dent compared to the much larger
entrenched Unix user-base and they don't change the nature of the development
much.

> Absolutely! In addition, even if you don't consider win32 a platform to run
> production databases on, the win32 port will help developers who work from
> windows boxes, which is the certainly the most widely used desktop environment.
> My former company would have loved the win32 port for exactly this reason, even
> though most of our servers were FreeBSD / Linux.

Oh sure, it'll be useful. But it doesn't make the difference between different
classes of software. It'll still the same Postgres with the same set of things
it's capable of handling once you get it running.

If you need 24x7, scalability to n terabytes or x transactions/s, guaranteed
data integrity in the face of various failures, none of the checklist items
you'll be looking for will be win32 support. PITR will probably be a factor in
meeting any of those requirements.

In any case, my post was mostly a troll, there's not really much point in
arguing with it. They're all useful features and I hope they're all in the
next version of postgres, whatever version number it's given :)

--
greg

--- Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> wrote:
>
> I don't call porting Postgres to run well on something like 40% of the
> world's servers (or whatever it is) "just another port".

Statistics is a tricky thing. IMHO, there are plenty of things that are much
more important than win32 port.

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Matthew T. O'Connor wrote:

> Christopher Kings-Lynne wrote:
>
>>> Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on
>>> dozens of
>>> OSes already. What's so exciting about one more? Even if it is a
>>> pathologically hard OS to port to. Just because it was hard doesn't
>>> mean it's
>>> useful.
>>
>>
>> I don't call porting Postgres to run well on something like 40% of
>> the world's servers (or whatever it is) "just another port".
>>
>> It could conveivably double Postgres's target audience, could attract
>> heaps of new users, new developers, new companies and put us in a
>> better position to compete with MySQL.
>>
>> I think it's actually a necessary port to keep the project alive in
>> the long term.
>
>
> Absolutely! In addition, even if you don't consider win32 a platform
> to run production databases on, the win32 port will help developers
> who work from windows boxes, which is the certainly the most widely
> used desktop environment. My former company would have loved the
> win32 port for exactly this reason, even though most of our servers
> were FreeBSD / Linux.

And my former company produced software that ran on Windows and *nix. We
would have loved to be able to ship PostgreSQL as our reference
database, but could not because there was no native Windows port.

We've been over this ground before. It might not be important to some
people but it is important for a hell of a lot of others.

cheers

andrew

> Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens of
> OSes already. What's so exciting about one more? Even if it is a
> pathologically hard OS to port to. Just because it was hard doesn't mean it's
> useful.
>

Absolutely correct.
PostgreSQL runs on so many platforms. I cannot see a reason why we
should put effort in an inheritly nasty operating system which will
cause A LOT of pain in the future.
I can already hear the question we will have to face ...
People using PostgreSQL are not MySQL or Access people - they know why
they are using Linux. I have seen somebody asking for Windows once or
twice in 4 yours. Is it worth the effort?
Of course, many people use Windows - I can understand that for desktop
PCs but personally I am in a bit different situation. We support
PostgreSQL which means that people will cut my head off if something
does not work. I don't trust Windows and I don't want to hunt bugs in
PostgreSQL which are caused by an inferious and inheritly nasty
operating system.

As far as versioning is concerned: I am not in favour of pumping the
version number to number. Here in Austria we call those things
"versionitis" - it is a Windows-disease and should be cured.

We have never lost against a different database because of a lower
version number.

I'd make 8.0 a "network release" meaning that 2pc, replication and
things like that are supported.

Regards,

Hans V1.0

--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at

>
> Joshua D. Drake wrote:
>
> > Hello,
> >
> > If Win32 actually makes it into 7.5 then yes I believe 8.0 would be
> > appropriate.
>
> It might be interesting to track Oracle's version number viz. its
> feature list. IOW, a PostgreSQL 8.0 database would be feature
> equivalent to an Oracle 8.0 database. That would mean:
>
> 1) PITR
> 2) Distributed Tx
> 3) Replication
> 4) Nested Tx
> 5) PL/SQL Exception Handling
>
> IMHO, a major version number jump should at least match the delta in
> features one finds in the commercial segment with their major version
> number bumps. Otherwise, I suspect it would be viewed as window
> dressing...
Good point. To me the best argument against so far.
>
> Could be wrong, though...
>
> Mike Mascari
> mascarm(at)mascari(dot)com
>
>
Regards, Christoph

Le Mardi 18 Novembre 2003 06:21, Greg Stark a écrit :
> Oh, and yeah, a win32 port. Yay, another OS port. Postgres runs on dozens
> of OSes already. What's so exciting about one more? Even if it is a
> pathologically hard OS to port to. Just because it was hard doesn't mean
> it's useful.

Dear Greg,

In your opinion, why did MySQL capture so many users quickly?

Is it because MySQL offers a nice and powerful solution? No, on the converse,
everyone knows that MySQL is not a reliable database. To some extent, MySQL
is not really ACID compliant. It cannot parse large queries with LEFT and
RIGHT joins. It does not offer reliable ODBC. And it does not evolve very
quickly. it does not support Unicode. There are no server-side languages.
etc...

So why did MySQL succeed? In my opinion, because Php and MySQL were both
available on Apache servers (GNU/Linux) and on home stations (Win32). Simple
as that.

This kind of cross-needs-effect is called a ***portfolio effect***. The
portfolio effect is the ***central marketing strategy*** of Microsoft when
releasing OS and Office suites together.

Because your Grand-mother owns a Win 95 station, she sends you files under
PowerPoint 95, in turn you invest in Office 2000 and send Excel 2000 files to
your brother, who in turn invests in Office XP and prints Word XP documents.
[<---Future readers in 200 years: all these names used tp be trademarks from
Microsoft in a time when a few people tried to lock-up ideas.-->].

And you end up with everyone upgrading Office and Windows. Now, without being
pretentious, I would like to remind this simple idea:

***Who lives by the sward, dies by the sward***

If we apply the same strategy as Microsoft or MySQL, PostgreSQL can conquer
the whole market. Not 1% like today, but 60% or more like Apache. Because we
are a community.

If you do not believe reaching 60% of market shares is possible, let us assume
that a PostgreSQL Win32 native port is available in 6 months. Immediately,
the following bundles would appear:

- PostgreSQL + PhpPgAdmin + pgAdmin -> a potential of 1 million users
- Apache2.0 + Php5 + PostgreSQL -> a potential of 5 million users
- OpenOffice + PostgreSQL -> a potential of 10 million users
- Some MS Access replacement -> a potential of 2 million users
- there are many others...

For me, this makes 60% of the market at least.
A 1% to 60% is not a small difference, it is a real gap.

Best regards,
Jean-Michel

Maybe the criteria for 8.0 should be in place upgrades... that would be
a major shift in the landscape of PostgreSQL...

Robert Treat

On Mon, 2003-11-17 at 21:20, Christopher Browne wrote:
> Oops! josh(at)agliodbs(dot)com (Josh Berkus) was seen spray-painting on a wall:
> > Given all that, don't people think it's time to jump to 8.0? Seems
> > like even 7.4 is hardly recognizable as the same database as 7.0.
>
> If wishes were fishes... Shouldn't we see what interesting features
> actually _do_ make it in?
>
> If Win32 support does get ready, and we get recursive queries (I'll
> point out different TODO items :-)) and Slony-1, PITR, and cache
> improvements make it in, then perhaps it's time to call it 8.0. A
> "cvs update -Pd" doesn't get me that yet, so it seems early.
>
> I'd _almost_ buy the story that 7.4 should have been called 8.0,
> although that _didn't_ happen because it 'just missed' PITR and Win32.
>
> The amusing approach would be to jump straight to 8.1 :-).
> --
> wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
> http://www.ntlug.org/~cbbrowne/postgresql.html
> ..you could spend *all day* customizing the title bar. Believe me. I
> speak from experience." -- Matt Welsh
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match

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

Uz.ytkownik Jean-Michel POURE napisa?:

>
> For me, this makes 60% of the market at least.
> A 1% to 60% is not a small difference, it is a real gap.
>

Don't forget that success isn't always connected with technical things
(very good example is MySQL :-)) - PostgreSQL needs a good marketing,
clear strategy and identity. But for sure Win32 port will be a huge step.

There are other databases which have Win32 native version and aren't so
popular (like Firebird...)... So my proposition to PostgreSQL's team is
to think also about SMI -> Strategy Marketing Identity...

Christopher Browne wrote:

> Oops! josh(at)agliodbs(dot)com (Josh Berkus) was seen spray-painting on a wall:
>> Given all that, don't people think it's time to jump to 8.0? Seems
>> like even 7.4 is hardly recognizable as the same database as 7.0.
>
> If wishes were fishes... Shouldn't we see what interesting features
> actually _do_ make it in?
>
> If Win32 support does get ready, and we get recursive queries (I'll
> point out different TODO items :-)) and Slony-1, PITR, and cache
> improvements make it in, then perhaps it's time to call it 8.0. A
> "cvs update -Pd" doesn't get me that yet, so it seems early.
>
> I'd _almost_ buy the story that 7.4 should have been called 8.0,
> although that _didn't_ happen because it 'just missed' PITR and Win32.
>
> The amusing approach would be to jump straight to 8.1 :-).

The real fun would be to let it start as 8, then 8.1 and so on ...

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 #

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Peter wrote:
>> Also note that most major number
>> changes in the past weren't because the features were cool, but because
>> the project has moved to a new phase. I don't see any such move
>> happening.

> Now that is interesting. I missed that. Can you explain how that worked
> with 7.0?

Personally I thought that the 6.5->7.0 jump was a mistake ... but that's
water over the dam now.

I would be willing to call a PG release 8.0 when it has built-in
replication support --- that would be the sort of major-league
functionality jump that would justify a top-number bump.

There are not that many other plausible reasons for a top-number bump
that I can think of right now. PG is really getting to be a pretty
mature product, and ISTM that should be reflected in a disinclination
to call it "all new".

You can be dead certain that a Windows port will not be sufficient
reason to call it 8.0. Perhaps 6.6.6 would the right starting version
number for that one ;-)

regards, tom lane

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

<snip>
> I would be willing to call a PG release 8.0 when it has built-in
> replication support --- that would be the sort of major-league
> functionality jump that would justify a top-number bump.
ACK.
A major release (for me) implies some really major improvement.
Replication would be such a thing.

BTW: is there anything working yet in this direction ?
I know several "userland" implementations (w/ triggers), and I also
doing symetric (masterless) replication in my middleware framework,
but when will pgsql be able to do it by itself ?
And when will probably load balancing come ?

hmm, which commerical RDBMS (beside oracle) provide this already ?

<snip>
> You can be dead certain that a Windows port will not be sufficient
> reason to call it 8.0. Perhaps 6.6.6 would the right starting version
> number for that one ;-)
*rofl*

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(at)metux(dot)de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

Enrico Weigelt wrote:
> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> <snip>
> > I would be willing to call a PG release 8.0 when it has built-in
> > replication support --- that would be the sort of major-league
> > functionality jump that would justify a top-number bump.
> ACK.
> A major release (for me) implies some really major improvement.
> Replication would be such a thing.
>
> BTW: is there anything working yet in this direction ?
> I know several "userland" implementations (w/ triggers), and I also
> doing symetric (masterless) replication in my middleware framework,
> but when will pgsql be able to do it by itself ?
> And when will probably load balancing come ?

All replication work is being done as add-ons because then people can
choose the replication solution that works best for them. We don't
think a single solution can fit all needs.

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

> BTW: is there anything working yet in this direction ?
> I know several "userland" implementations (w/ triggers), and I also
> doing symetric (masterless) replication in my middleware framework,
> but when will pgsql be able to do it by itself ?

There is only one production and shipping replication that does not
require triggers that I know of and that is ours (Command Prompt).
It is also not a userland app but actually part of the PostgreSQL engine.

There is also ERServer which was first (?) but it tends to be a bit
of a beast to maintain.

There is Slony-I which is showing promise but is a Trigger based option.

Others include Peer Direct (Which I believe is query based) and
PgCluster which is query based.

Each solution has pro's and cons. Slony-I for example appears to be
better when doing mass updates or deletes than Replicator.

On the argument of significant features for 7.5:

Win32 Native
PITR
Nested Transactions
Background Writer....

J

> And when will probably load balancing come ?
>
> hmm, which commerical RDBMS (beside oracle) provide this already ?
>
> <snip>
>
>>You can be dead certain that a Windows port will not be sufficient
>>reason to call it 8.0. Perhaps 6.6.6 would the right starting version
>>number for that one ;-)
>
> *rofl*
>
> cu

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

* Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:

<snip>
> All replication work is being done as add-ons because then people can
> choose the replication solution that works best for them. We don't
> think a single solution can fit all needs.
hmm. I didn't have the time yet to google about them ...

Where do the come in ?
Hast the postmaster to be patched and recompiled ?

Is there anywhere an overview about them ?
Are they publically available w/o fees ?

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(at)metux(dot)de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

* Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:

<snip>
> There is only one production and shipping replication that does not
> require triggers that I know of and that is ours (Command Prompt).
> It is also not a userland app but actually part of the PostgreSQL engine.
Ah. Has pgsql to be patched for that or can it be simply dropped-in
like external (C) functions/procedures ?

What about lazy replication (i.e. when some node is running but not
online for a while), masterless replication (all nodes are equal)
or journaling ?
My application/framework-level solves this, but
a) requires some special table layout (first attrs have to be inode+mtime),
b) not suited for high update-rates (relly too slow for that)
but it is already working quite stable for several years :)

<snip>
> Each solution has pro's and cons. Slony-I for example appears to be
> better when doing mass updates or deletes than Replicator.
yeah, on subsequent mass-updates on just one host per table at certain time,
my stuff is also good, since it works w/ batching. but when multiple hosts
do heavy updates on the same table, it may run into conflicts.

<snip>
> On the argument of significant features for 7.5:
>
> Win32 Native
> PITR
Stupid question: whats PITR ?
> Nested Transactions
> Background Writer....
Background-Write = write-behind ?

BTW: how stable is the current pgsql against powerfails or kill -9 ?

cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact(at)metux(dot)de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------

Hello,

This is probably better suited for something not on pgsql-advocacy. I
will respond offlist.

Sincerely,

Joshua D. Drake

Enrico Weigelt wrote:
> * Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
> <snip>
>
>>There is only one production and shipping replication that does not
>>require triggers that I know of and that is ours (Command Prompt).
>>It is also not a userland app but actually part of the PostgreSQL engine.
>
> Ah. Has pgsql to be patched for that or can it be simply dropped-in
> like external (C) functions/procedures ?
>
> What about lazy replication (i.e. when some node is running but not
> online for a while), masterless replication (all nodes are equal)
> or journaling ?
> My application/framework-level solves this, but
> a) requires some special table layout (first attrs have to be inode+mtime),
> b) not suited for high update-rates (relly too slow for that)
> but it is already working quite stable for several years :)
>
> <snip>
>
>>Each solution has pro's and cons. Slony-I for example appears to be
>>better when doing mass updates or deletes than Replicator.
>
> yeah, on subsequent mass-updates on just one host per table at certain time,
> my stuff is also good, since it works w/ batching. but when multiple hosts
> do heavy updates on the same table, it may run into conflicts.
>
> <snip>
>
>>On the argument of significant features for 7.5:
>>
>>Win32 Native
>>PITR
>
> Stupid question: whats PITR ?
>
>>Nested Transactions
>>Background Writer....
>
> Background-Write = write-behind ?
>
> BTW: how stable is the current pgsql against powerfails or kill -9 ?
>
>
> cu

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

> Where do the come in ?
> Hast the postmaster to be patched and recompiled ?

No.

> Is there anywhere an overview about them ?

http://gborg.postgresql.org/project/slony1/projdisplay.php

> Are they publically available w/o fees ?

Yes.

This probably has been discussed and is probably a very minor point, but
consider how many more years we want to be able to use the <single
digit>.<single digit> major release numbering.

Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to
8.0 now, then we have up until 2023.

Also we have 1 more chance to skip major number: 8.x -> 9.0. Imagine
what features will there be in 9.0 that is ground-breaking enough.
Because after that, we don't have any more major number to jump into
without going into 2 digits.

I personally don't see the major number as a very magical thing. Look at
Linux for example. People still see 2.6 as very different/ahead compared
to 2.4...

--
dave

В Сбт, 05.06.2004, в 10:28, David Garamond пишет:
> This probably has been discussed and is probably a very minor point, but
> consider how many more years we want to be able to use the <single
> digit>.<single digit> major release numbering.
>
> Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
> then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to
> 8.0 now, then we have up until 2023.
>
> Also we have 1 more chance to skip major number: 8.x -> 9.0. Imagine
> what features will there be in 9.0 that is ground-breaking enough.
> Because after that, we don't have any more major number to jump into
> without going into 2 digits.

What's the problem with 7.10?

--
Markus Bertheau <twanger(at)bluetwanger(dot)de>

From: David Garamond
Sent: Sat 6/5/2004 9:28 AM
Cc: postgresql advocacy; pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?

Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to
8.0 now, then we have up until 2023.

Hi Dave,

I might be missing the point, but why can't we go to double figures? MS Office has, HP-UX has, OS-X, Norton AV has, Madrake Linux has...

Regards, Dave

Dave Page wrote:
> From: David Garamond
> Sent: Sat 6/5/2004 9:28 AM
> Cc: postgresql advocacy; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] [pgsql-advocacy] Not 7.5, but 8.0 ?
>
> Assuming 1 year between major releases (7.3.0 -> 7.4.0 = +- 1 year),
> then we have 7.5-9.9 = 26 years = up until +- jul 2030. if we skip to
> 8.0 now, then we have up until 2023.
>
> Hi Dave,
>
> I might be missing the point, but why can't we go to double figures? MS
> Office has, HP-UX has, OS-X, Norton AV has, Madrake Linux has...

Of course we can, I didn't say we can't. But double digits are sometimes
undesirable because it can break some things. For example, a simple
shell or Perl script might try to compare the version of two data
directories by comparing the content of PG_VERSION stringwise. It then
concludes that 7.10 is smaller than 7.4.

Granted, the script itself is faulty, but since some other OS projects
(like Ruby, with the same x.y.z numbering) do guarantee they never will
have double digits in version number component than people might think
the same too and thus the habit of stringwise version comparison continues.

--
dave

David Garamond <lists(at)zara(dot)6(dot)isreserved(dot)com> writes:
> Granted, the script itself is faulty, but since some other OS projects
> (like Ruby, with the same x.y.z numbering) do guarantee they never will
> have double digits in version number component

Oh? What's their plan for the release after 9.9.9?

In practice, non-broken bits of code don't make such an assumption,
as there have always been lots of projects with double-digit version
components. A quick grep for locally-installed packages finds

autoconf-2.53.tar.gz
binutils-2.10.1.tar.gz
bison-1.875.tar.gz
cvs-1.10.7.tar.gz
emacs-19.34b.tar.gz
expect-5.38.tar.gz
gcc-2.95.3.tar.gz
gettext-0.11.5.tar.gz
ghostscript-6.50.tar.gz
lesstif-0.89.9.tar.gz
lsof_4.47_W.tar.gz
make-3.79.1.tar.gz
mysql-3.23.29a-gamma.tar.gz
netcat-1.10.tar.gz
ntp-4.0.99k.tar.gz
procmail-3.22.tar.gz
sendmail.8.12.11.tar.gz
tar-1.13.tar.gz

IMHO trying to avoid double-digit component numbers is just silly.

regards, tom lane

Tom Lane wrote:
>>Granted, the script itself is faulty, but since some other OS projects
>>(like Ruby, with the same x.y.z numbering) do guarantee they never will
>>have double digits in version number component
>
> Oh? What's their plan for the release after 9.9.9?

As for Ruby, it probably won't expect > 9.9.9 in any foreseeable future.
It takes +- 10 years to get to 1.8.1. Same with Python. But Perl will
have 5.10.0.

--
dave

"David Garamond" <lists(at)zara(dot)6(dot)isreserved(dot)com> wrote:
> Tom Lane wrote:
> > Oh? What's their plan for the release after 9.9.9?
>
> As for Ruby, it probably won't expect > 9.9.9 in any foreseeable future.
> It takes +- 10 years to get to 1.8.1. Same with Python. But Perl will
> have 5.10.0.
>
You cannot seriously propose that the version number in itself should
prevent a 10th bugfix on some branch just to satisfy the possible existence
of an incorrect version number parser somewhere?

> I personally don't see the major number as a very magical thing. Look at
> Linux for example. People still see 2.6 as very different/ahead compared
> to 2.4...
>
IMHO a discussion concerning rules controlling when and why things should be
major versus minor releases is needed rather than invalidating the
significance of major/minor/bugfix altogether. What you propose is very
close to suggesting one single number ranging from 001 to 999. I don't think
that will meet much sympathy either.

Kind regards,

Thomas Hallgren

"David Garamond" <lists(at)zara(dot)6(dot)isreserved(dot)com> wrote in message
news:40C2BCEC(dot)4040104(at)zara(dot)6(dot)isreserved(dot)com(dot)(dot)(dot)
> Tom Lane wrote:
> >>Granted, the script itself is faulty, but since some other OS projects
> >>(like Ruby, with the same x.y.z numbering) do guarantee they never will
> >>have double digits in version number component
> >
>
> --
> dave
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>