Thread: 7.4?

7.4?

From
Dmitry Tkach
Date:
Do you guys have any tentative estimates about when 7.4 is going to get released?
What is the timeframe? Also, what is going to be there that is not in 7.3?
I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to wait for 7.4 and go
rightthere... 

Thanks!

Dima


Re: 7.4?

From
Dennis Gearon
Date:
If it ain't broke,
don't fix it!

2/24/2003 11:36:33 AM, Dmitry Tkach <dmitry@openratings.com> wrote:

>
>Do you guys have any tentative estimates about when 7.4 is going to get released?
>What is the timeframe? Also, what is going to be there that is not in 7.3?
>I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to
wait for 7.4 and go right there...
>
>Thanks!
>
>Dima
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org
>




Re: 7.4?

From
Dmitry Tkach
Date:
Dennis Gearon wrote:

>If it ain't broke,
>don't fix it!
>
Yeah... I know. That's exactly where I am coming from :-)
I am sitting on about a 200G database here, and I know what a pain in
the neck it is going to be to migrate it (plus, I've got some "C"
functions, that, as I figured recently do not even compile with 7.3) :-(

But there is some stuff in 7.3 that I really miss - like function
returning tuples, prepared and saved query plans, vacuum (full)
behaviour etc...
Besides, Tom Lane has said some really scarry things about possible data
corruption/loss stuff in 7.2...

So, it sounds like I am going to have to go through this upgrade
nightmare... the only question is - when it is a good time to do it...

Dima


>
>2/24/2003 11:36:33 AM, Dmitry Tkach <dmitry@openratings.com> wrote:
>
>
>
>>Do you guys have any tentative estimates about when 7.4 is going to get released?
>>What is the timeframe? Also, what is going to be there that is not in 7.3?
>>I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to
>>
>>
>wait for 7.4 and go right there...
>
>
>>Thanks!
>>
>>Dima
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 6: Have you searched our list archives?
>>
>>http://archives.postgresql.org
>>
>>
>>
>
>
>
>



Re: 7.4?

From
Bruno Wolff III
Date:
On Mon, Feb 24, 2003 at 14:36:33 -0500,
  Dmitry Tkach <dmitry@openratings.com> wrote:
>
> Do you guys have any tentative estimates about when 7.4 is going to get
> released?
> What is the timeframe? Also, what is going to be there that is not in 7.3?
> I am currently on 7.2, and trying to find out whether it makes sense to
> upgrade to 7.3 now or to wait for 7.4 and go right there...

My opinion is that you should go to 7.3 now.

7.4 seems to have a ways to go before it is even going to be in beta, so it
will be a minimum of several months before it is released.

The change from 7.3 to 7.4 will likely be easier than going from
7.2 to 7.3 (because schemas are a big change in 7.3).

Re: 7.4?

From
Ericson Smith
Date:
Could someone summarize what would be the 3 changes that would have the
most impact in 7.4?

- Ericson Smith
eric@did-it.com

On Mon, 2003-02-24 at 14:05, Bruno Wolff III wrote:
> On Mon, Feb 24, 2003 at 14:36:33 -0500,
>   Dmitry Tkach <dmitry@openratings.com> wrote:
> >
> > Do you guys have any tentative estimates about when 7.4 is going to get
> > released?
> > What is the timeframe? Also, what is going to be there that is not in 7.3?
> > I am currently on 7.2, and trying to find out whether it makes sense to
> > upgrade to 7.3 now or to wait for 7.4 and go right there...
>
> My opinion is that you should go to 7.3 now.
>
> 7.4 seems to have a ways to go before it is even going to be in beta, so it
> will be a minimum of several months before it is released.
>
> The change from 7.3 to 7.4 will likely be easier than going from
> 7.2 to 7.3 (because schemas are a big change in 7.3).
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Ericson Smith <eric@did-it.com>


Re: 7.4?

From
Robert Treat
Date:
On Mon, 2003-02-24 at 14:29, Ericson Smith wrote:
> Could someone summarize what would be the 3 changes that would have the
> most impact in 7.4?
>

Impact to who?  :-)

1. Native Windows Support
2. Point In Time Recovery
3. Standard Replication Solution

(Please note that while these are all currently planned for 7.4, and are
actively being developed, I can't guarantee they will all be there.)

Robert Treat



Re: 7.4?

From
"scott.marlowe"
Date:
On 24 Feb 2003, Ericson Smith wrote:

> Could someone summarize what would be the 3 changes that would have the
> most impact in 7.4?

I would say the biggest impact from 7.2 to 7.3 are:

- Schemas and their support
- Indexing issues related to using C locale or anything else
- The less greedy type matching changes result in some indexes being
ignored that were once used.
- Old sequences and other things won't inherit dependency.  not a real
problem, just an fyi.

From 7.3 to 7.4 the biggest changes planned so far:
- windows native support <-- gartner gives it a 90% chance of making it
into the main disto... :-)
- fix for in() performance issue <-- already in CVS tip
- partitioning or tablespaces <-- who know?  seriously, who?
- vacuum will be able to compact out unused space <-- Tom Lane
- possible newer settings for the default postgresql.conf could
increase load on some machines to a point they may need to be reconfigured
to come up.

Data wise I don't think there's gonna be a lot that will mess up a 7.3 to
7.4 conversion so far that's gone by.


Re: 7.4?

From
Ericson Smith
Date:
> From 7.3 to 7.4 the biggest changes planned so far:
> - windows native support <-- gartner gives it a 90% chance of making it
> into the main disto... :-)
> - fix for in() performance issue <-- already in CVS tip
> - partitioning or tablespaces <-- who know?  seriously, who?
> - vacuum will be able to compact out unused space <-- Tom Lane

Will we be able to run the new vacuum system without locking the tables?

Currently our database is at about 15gigs. Over the period of a month,
it grows to about 25gigs (10Gb wasted space). Every month we have a
cleanup routine which involves copying the most actively updated tables
to text, and importing the data again. We vacuum every night and analyze
4 times per day, but we're loath to do a VACUUM FULL because of the
table locking issues (locking some of the tables would break the
operation of some of our 24/7 systems), hence we prefer to stop the db
about once per month, eat the downtime as scheduled (about 1.5 hours),
and get back to business for the next 30 days again.

We're all behind Tom on this change :-)

- Ericson Smith
eric@did-it.com




--
Ericson Smith <eric@did-it.com>


Re: 7.4?

From
Tom Lane
Date:
Dmitry Tkach <dmitry@openratings.com> writes:
> I am currently on 7.2, and trying to find out whether it makes sense to upgrade to 7.3 now or to wait for 7.4 and go
rightthere... 

And when 7.4 is out, won't you be wondering whether to wait for 7.5?

I'd say update when the current version seems worth the effort of
updating to you.  Don't think about the future, or you'll be chasing
mirages forever.

Anyway, to answer your question: the current timeframe for 7.4 beta is
April-ish.  Sometime after that it will go final.  Sometime after
*that*, a prudent DBA might think about migrating to it.  How long do
you want to wait?

            regards, tom lane

Re: 7.4?

From
Joe Tomcat
Date:
On Mon, 2003-02-24 at 12:28, Robert Treat wrote:
> On Mon, 2003-02-24 at 14:29, Ericson Smith wrote:
> > Could someone summarize what would be the 3 changes that would have the
> > most impact in 7.4?
> >
>
> Impact to who?  :-)
>
> 1. Native Windows Support
> 2. Point In Time Recovery
> 3. Standard Replication Solution

#3 is a very big deal for business users.  I am very glad to hear it is
in 7.4.  Point in time recovery is also an important thing for biz
users.



Re: 7.4?

From
Medi Montaseri
Date:
How about auto-vacuum....

Robert Treat wrote:

>On Mon, 2003-02-24 at 14:29, Ericson Smith wrote:
>
>
>>Could someone summarize what would be the 3 changes that would have the
>>most impact in 7.4?
>>
>>
>>
>
>Impact to who?  :-)
>
>1. Native Windows Support
>2. Point In Time Recovery
>3. Standard Replication Solution
>
>(Please note that while these are all currently planned for 7.4, and are
>actively being developed, I can't guarantee they will all be there.)
>
>Robert Treat
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>
>




Re: 7.4?

From
"scott.marlowe"
Date:
On 24 Feb 2003, Ericson Smith wrote:

>
> > From 7.3 to 7.4 the biggest changes planned so far:
> > - windows native support <-- gartner gives it a 90% chance of making it
> > into the main disto... :-)
> > - fix for in() performance issue <-- already in CVS tip
> > - partitioning or tablespaces <-- who know?  seriously, who?
> > - vacuum will be able to compact out unused space <-- Tom Lane
>
> Will we be able to run the new vacuum system without locking the tables?

Vacuum only locks the tables now for a second or so.

You might want to look at using regular vacuums more often.  In my
testing, vacuum (non full) uses <2% of the CPU on a heavily loaded server.
Between the low load of vacuum and having higher fsm settings, you might
obviate the need to regular vacuum any more than once a day or week or
whatever.




reindex

From
"Andrew Bartley"
Date:
Hi all,

I am having trouble reindexing our DB.

We are running  PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC gcc
(GCC) 3.2.1

backend> reindex database evolvo force
NOTICE:  relation 1247 was reindexed
NOTICE:  relation 1249 was reindexed
NOTICE:  relation 1259 was reindexed
NOTICE:  relation 1261 was reindexed
NOTICE:  relation 1262 was reindexed
ERROR:  cannot create pg_inherits_relid_seqno_index: File exists

Can someone help me.

Thanks

Andrew Bartley


Re: 7.4?

From
Andrew Sullivan
Date:
On Mon, Feb 24, 2003 at 03:53:14PM -0500, Ericson Smith wrote:
>
> Will we be able to run the new vacuum system without locking the tables?

I believe the new vacuum stuff is just to help on btree indexes.  The
current vacuum doesn't lock the tables, either.

> Currently our database is at about 15gigs. Over the period of a month,
> it grows to about 25gigs (10Gb wasted space). Every month we have a
> cleanup routine which involves copying the most actively updated tables
> to text, and importing the data again. We vacuum every night and analyze
> 4 times per day, but we're loath to do a VACUUM FULL because of the
> table locking issues (locking some of the tables would break the

It sounds like either your free space map is not set correctly, or
you have ever-growing indexes.  Reindexing would be enough for this
problem.  There are still some 24/7-operation problems with having to
reindex.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: 7.4?

From
Andrew Sullivan
Date:
On Mon, Feb 24, 2003 at 04:12:41PM -0500, Tom Lane wrote:

> April-ish.  Sometime after that it will go final.  Sometime after
> *that*, a prudent DBA might think about migrating to it.  How long do

This is a good point: 7.3 (i.e. with no dot-release) was a bad bet
for production use, because of the numbers of changes in the system;
PITR alone will require enough changes that I wouldn't trust it for
production use immediately.  Just because the software has been
released doesn't mean it's ready to put everywhere yet, especially
when you consider that dropping back a version is not something
really contemplated by the current upgrade path.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: 7.4?

From
Ericson Smith
Date:
On Tue, 2003-02-25 at 08:18, Andrew Sullivan wrote:
> I believe the new vacuum stuff is just to help on btree indexes.  The
> current vacuum doesn't lock the tables, either.
I was actually thinking about a VACUUM FULL. Currently we have not
problems doing a regular VACUUM. That said, will the new vacuum free as
much space like the current vacuum full, without the handicap of table
locking?

> It sounds like either your free space map is not set correctly, or
> you have ever-growing indexes.  Reindexing would be enough for this
> problem.  There are still some 24/7-operation problems with having to
> reindex.
>
We will definitely try the reindex as suggested.

--
Ericson Smith <eric@did-it.com>


Re: 7.4?

From
Andrew Sullivan
Date:
On Tue, Feb 25, 2003 at 09:41:13AM -0500, Ericson Smith wrote:

> I was actually thinking about a VACUUM FULL. Currently we have not

VACUUM FULL will always block.  To make a rather nasty comparison,
it's like defragging your disk under Windows: you can't really access
a file which is being moved around.

> problems doing a regular VACUUM. That said, will the new vacuum free as
> much space like the current vacuum full, without the handicap of table
> locking?

Yes and no.  VACUUM FULL recovers space absolutely.  So if you know
that the table has really shrunk, and shrunk permanently (or similar
cases, like 100% of the table was replaced), then you need VACUUM
FULL.  Non-blocking VACUUM will make the freed space available to
Postgres, but not to the filesystem in general.  In other words, the
regular VACUUM should mean that your table size stabilises, given
that your database is always more or less the same number of tuples;
but it will be slightly larger on disk than that number of tuples
strictly requires.  (Is that clear?  If not, maybe someone else can
make it clearer.)

A
--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: reindex

From
Tom Lane
Date:
"Andrew Bartley" <abartley@evolvosystems.com> writes:
> We are running  PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC gcc
> (GCC) 3.2.1

> backend> reindex database evolvo force
> NOTICE:  relation 1247 was reindexed
> NOTICE:  relation 1249 was reindexed
> NOTICE:  relation 1259 was reindexed
> NOTICE:  relation 1261 was reindexed
> NOTICE:  relation 1262 was reindexed
> ERROR:  cannot create pg_inherits_relid_seqno_index: File exists

If you've been running this database long enough to wrap around the OID
counter, then this failure is possible (though I wouldn't have thought
it probable).  Try a few times and it'll probably succeed eventually.

            regards, tom lane

Re: 7.4?

From
Neil Conway
Date:
On Mon, 2003-02-24 at 15:28, Robert Treat wrote:
> 3. Standard Replication Solution

I'd be quite surprised to see this in 7.4. Not that I wouldn't love to
have someone contribute it -- I just wouldn't bet on it being in 7.4 if
the beta date is around the middle of April.

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC




Re: 7.4?

From
Robert Treat
Date:
On Sat, 2003-02-22 at 07:56, Joe Tomcat wrote:
> On Mon, 2003-02-24 at 12:28, Robert Treat wrote:
> > On Mon, 2003-02-24 at 14:29, Ericson Smith wrote:
> > > Could someone summarize what would be the 3 changes that would have the
> > > most impact in 7.4?
> > >
> >
> > Impact to who?  :-)
> >
> > 1. Native Windows Support
> > 2. Point In Time Recovery
> > 3. Standard Replication Solution
>
> #3 is a very big deal for business users.  I am very glad to hear it is
> in 7.4.  Point in time recovery is also an important thing for biz
> users.
>

For the record let me re-emphasize that none of these are guaranteed to
be in 7.4.  They are all actively being worked on, and the current hopes
of the developers is that they will all be in, but it is quite possible
that one of these might not make it in (and most likely to not make
would be replication imho)

Robert Treat



Re: 7.4?

From
Peter Eisentraut
Date:
Neil Conway writes:

> I'd be quite surprised to see this in 7.4. Not that I wouldn't love to
> have someone contribute it -- I just wouldn't bet on it being in 7.4 if
> the beta date is around the middle of April.

When someone says that beta is planned April-ish, that means beta will be
in June and the final release will be in September.  Mark my words.

--
Peter Eisentraut   peter_e@gmx.net


Re: 7.4?

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> Neil Conway writes:
>> I'd be quite surprised to see this in 7.4. Not that I wouldn't love to
>> have someone contribute it -- I just wouldn't bet on it being in 7.4 if
>> the beta date is around the middle of April.

> When someone says that beta is planned April-ish, that means beta will be
> in June and the final release will be in September.  Mark my words.

If all three of these changes (Windows port, pitr, replication) get in
before feature freeze, I wouldn't want to bet that final will be any
sooner than that --- we'll have lots of testing to do.

But we *will* freeze 7.4 features in April, and at the rate work appears
to be progressing, I wouldn't want to bet that any of these features
will be in by then ;-).  If they don't make the cut, 7.4 final will
probably be a lot sooner than September.

            regards, tom lane

Re: 7.4?

From
"Ed L."
Date:
On Tuesday February 25 2003 10:30, Robert Treat wrote:
> On Sat, 2003-02-22 at 07:56, Joe Tomcat wrote:
> > On Mon, 2003-02-24 at 12:28, Robert Treat wrote:
> > > On Mon, 2003-02-24 at 14:29, Ericson Smith wrote:
> > > > Could someone summarize what would be the 3 changes that
> > > > would have the most impact in 7.4?
> > >...
> > > 3. Standard Replication Solution
> >
> > #3 is a very big deal for business users.  I am very glad to hear
> > it is in 7.4....
>
> For the record let me re-emphasize that none of these are
> guaranteed to be in 7.4.  They are all actively being worked on,
> and the current hopes of the developers is that they will all be
> in, but it is quite possible that one of these might not make it in
> (and most likely to not make would be replication imho)

And do I understand correctly the replication to be eventually
included will be an embedded syncronous replication solution based on
Postgres-R and the Spread GCS?  I'm asking because we have need for
an *asyncronous*, non-embedded solution, and would like to stay on
the beaten path if possible.

Ed

Re: 7.4?

From
Neil Conway
Date:
On Tue, 2003-02-25 at 22:44, Ed L. wrote:
> And do I understand correctly the replication to be eventually
> included will be an embedded syncronous replication solution based on
> Postgres-R and the Spread GCS?

No, I don't think that's set in stone (although I can't speak for the
core team). While I think Postgres-R is promising, there might be room
for additional replication implementations that cater to different sets
of requirements.

IMHO, eventually providing solutions for both synchronous and
asynchronous replication would be a good idea.

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC




Re: 7.4?

From
Tom Lane
Date:
Neil Conway <neilc@samurai.com> writes:
> On Tue, 2003-02-25 at 22:44, Ed L. wrote:
>> And do I understand correctly the replication to be eventually
>> included will be an embedded syncronous replication solution based on
>> Postgres-R and the Spread GCS?

> No, I don't think that's set in stone (although I can't speak for the
> core team). While I think Postgres-R is promising, there might be room
> for additional replication implementations that cater to different sets
> of requirements.

There absolutely *is* room for multiple replication implementations.
AFAICS there's no one-size-fits-all approach.  I did and still do like
Postgres-R as a pretty useful approach, but it should not be mistaken
for The One True Path.

Also, there are nontrivial licensing issues involved.  The PG-R design
depends on an underlying "group communication" system, which is a
nontrivial bit of software that none of the core team wants to rewrite.
But none of the available GC systems are BSD-license open source.  We
had had some hopes of getting Spread to offer BSD terms, but that seems
to have fallen through.  So right now, PG-R is on the outside looking
in, as far as inclusion in the core distribution goes :-(

            regards, tom lane

Re: 7.4?

From
"Ed L."
Date:
On Tuesday February 25 2003 11:52, Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
> > On Tue, 2003-02-25 at 22:44, Ed L. wrote:
> >> And do I understand correctly the replication to be eventually
> >> included will be an embedded syncronous replication solution
> >> based on Postgres-R and the Spread GCS?
> >
> > No, I don't think that's set in stone (although I can't speak for
> > the core team). While I think Postgres-R is promising, there
> > might be room for additional replication implementations that
> > cater to different sets of requirements.
>
> There absolutely *is* room for multiple replication
> implementations. AFAICS there's no one-size-fits-all approach.  I
> did and still do like Postgres-R as a pretty useful approach, but
> it should not be mistaken for The One True Path.

That's good to hear.  We're looking for an asyncronous, non-embedded,
master-slave replication solution.  Among 7 pgsql replication
projects I've reviewed lately, the best prospects right now appear to
be rserv (testing it now) or failing that, some enhancements to
DBMirror.  Is there any near consensus among the core developers on
the best open source asyncronous solution as of today?

Ed


Re: 7.4?

From
"Ed L."
Date:
On Tuesday February 25 2003 11:52, Tom Lane wrote:
>
> Also, there are nontrivial licensing issues involved.  The PG-R
> design depends on an underlying "group communication" system, which
> is a nontrivial bit of software that none of the core team wants to
> rewrite. But none of the available GC systems are BSD-license open
> source.  We had had some hopes of getting Spread to offer BSD
> terms, but that seems to have fallen through.  So right now, PG-R
> is on the outside looking in, as far as inclusion in the core
> distribution goes :-(

Is anyone aware of particular reasons why the group is pushing on a
syncronous solution?  I'm sure they have good reasons, but I would've
assumed an asyncronous solution would be far more applicable for
simple redundancy as opposed to syncronicity for high-performance
clusters, not too mention being far simpler implementations.

Ed

Re: 7.4?

From
Joe Tomcat
Date:
On Tue, 2003-02-25 at 23:53, Ed L. wrote:
> On Tuesday February 25 2003 11:52, Tom Lane wrote:
> >
> > Also, there are nontrivial licensing issues involved.  The PG-R
> > design depends on an underlying "group communication" system, which
> > is a nontrivial bit of software that none of the core team wants to
> > rewrite. But none of the available GC systems are BSD-license open
> > source.  We had had some hopes of getting Spread to offer BSD
> > terms, but that seems to have fallen through.  So right now, PG-R
> > is on the outside looking in, as far as inclusion in the core
> > distribution goes :-(
>
> Is anyone aware of particular reasons why the group is pushing on a
> syncronous solution?  I'm sure they have good reasons, but I would've
> assumed an asyncronous solution would be far more applicable for
> simple redundancy as opposed to syncronicity for high-performance
> clusters, not too mention being far simpler implementations.

Some business needs absolutely must have synchronus replication.  You're
right that most users want async so they can have clusters serving data
out, but there are some very good reasons for sync:

1. Financial transactions MUST have off-site sync replication.

2. If you have a cluster of servers, sync guarantees that all the data
are in a consistent state.  Ease of administration and reliability may
be worth the slight performance penalty.

3. For servers on a fast LAN, sync may not make much of a difference on
performance.

I personally think that sync should be used in more cases than is
generally thought.  We can get very reliable LANs and even WAN links,
and if I know that the data are always consistent, that makes my life
much much easier than having to worry about cases where they are not.



Re: 7.4?

From
Hervé Piedvache
Date:
Le Mercredi 26 Février 2003 07:52, Tom Lane a écrit :
> Neil Conway <neilc@samurai.com> writes:
> > On Tue, 2003-02-25 at 22:44, Ed L. wrote:
> >> And do I understand correctly the replication to be eventually
> >> included will be an embedded syncronous replication solution based on
> >> Postgres-R and the Spread GCS?
> >
> > No, I don't think that's set in stone (although I can't speak for the
> > core team). While I think Postgres-R is promising, there might be room
> > for additional replication implementations that cater to different sets
> > of requirements.
>
> There absolutely *is* room for multiple replication implementations.
> AFAICS there's no one-size-fits-all approach.  I did and still do like
> Postgres-R as a pretty useful approach, but it should not be mistaken
> for The One True Path.
>
> Also, there are nontrivial licensing issues involved.  The PG-R design
> depends on an underlying "group communication" system, which is a
> nontrivial bit of software that none of the core team wants to rewrite.
> But none of the available GC systems are BSD-license open source.  We
> had had some hopes of getting Spread to offer BSD terms, but that seems
> to have fallen through.  So right now, PG-R is on the outside looking
> in, as far as inclusion in the core distribution goes :-(
>
>             regards, tom lane

You mean the PG-R project will no be included in the PostgreSQL project
unless someone rewrite the Spread GCS concept or similar system in a BSD
licence ?

What a bad news for the community ... ! :o(

PG-R seems to be the best integrated solution of the moment ... Still a lot
of work ... but Darren and others are making a real good job !

DBMirror or rserv (commercial application) seems to be only triggers, and
little demon not included in PostgreSQL system ... as PG-R is ...

PostgreSQL really need an official Replication solution to be definitively
secured in a productive environnement ... and I think I'm not the only one
thinking like that ... looking the survey of Postgres.org web site :
http://www.postgresql.org/survey.php?View=1&SurveyID=9
--
Hervé Piedvache

Elma Ingénierie Informatique
6 rue du Faubourg Saint-Honoré
F-75008 - Paris - France
Tel. 33-144949901
fax. 33-144949902

Function example

From
"Roberto de Amorim"
Date:
could anyone send me an example of CREATE FINTION using 'plpgsql' as
language and using paramters (more then 1)?
please

I don't know how to manipulate the params into the function...

TIA

Roberto de Amorim


Re: 7.4?

From
Tom Lane
Date:
"Ed L." <pgsql@bluepolka.net> writes:
> Is anyone aware of particular reasons why the group is pushing on a
> syncronous solution?  I'm sure they have good reasons, but I would've
> assumed an asyncronous solution would be far more applicable for

You're just showing bias in the other direction ;-).

Back when I was working for Great Bridge and got to spend a fair amount
of time at trade shows talking to potential customers, the thing we
heard over and over again was that people wanted multiple servers for
reliability/redundancy.  That goal seems to me to be best served by a
symmetric multi-master configuration, which is difficult if not
impossible to do with async replication.

There are certainly plenty of other scenarios where async works as well
or better, but that one seemed to be where the market was, at least in
terms of the presence of customers who might be willing to pay to have
it developed.  So that's what the ex-Great-Bridgers among core have been
thinking about doing first.  Also, there already is a credible async
replication alternative (PostgreSQL Inc's erserv), so filling the vacuum
for a sync solution seems higher-priority than doing another async
solution.

            regards, tom lane

Re: 7.4?

From
Tom Lane
Date:
=?iso-8859-15?q?Herv=E9=20Piedvache?= <herve@elma.fr> writes:
> Le Mercredi 26 F�vrier 2003 07:52, Tom Lane a �crit :
>> But none of the available GC systems are BSD-license open source.  We
>> had had some hopes of getting Spread to offer BSD terms, but that seems
>> to have fallen through.  So right now, PG-R is on the outside looking
>> in, as far as inclusion in the core distribution goes :-(

> You mean the PG-R project will no be included in the PostgreSQL project
> unless someone rewrite the Spread GCS concept or similar system in a BSD
> licence ?

Well, we certainly won't be bundling Spread into the distribution if
it's not got a compatible license.  I had originally hoped that the
PG-R project would end by having a complete sync replication solution
included in the standard PG distribution, but that goal is looking out
of reach at the moment.

            regards, tom lane

Re: Function example

From
Darko Prenosil
Date:
On Wednesday 26 February 2003 12:55, Roberto de Amorim wrote:
> could anyone send me an example of CREATE FINTION using 'plpgsql' as
> language and using paramters (more then 1)?
> please
>
> I don't know how to manipulate the params into the function...
>
See: http://developer.postgresql.org/docs/postgres/plpgsql-examples.html

Re: 7.4?

From
"Ed L."
Date:
On Wednesday February 26 2003 3:55, Hervé Piedvache wrote:
>
> PG-R seems to be the best integrated solution of the moment ...
> Still a lot of work ... but Darren and others are making a real
> good job !
>
> DBMirror or rserv (commercial application) seems to be only
> triggers, and little demon not included in PostgreSQL system ... as
> PG-R is ...

Remember there are distinct needs for both syncronous and asyncronous
solutions.  PG-R is a *syncronous* solution.  Solutions like
DBMirror, rserv, and eRServer, on the other hand, are asyncronous
solutions and thus have a complimentary role.

Ed

Re: 7.4?

From
Medi Montaseri
Date:
How about a feature as in Informix where you could specify a database_id
where then
thru a realm.conf file you map that id to a hostname:databasename

then saying

database.schema.table mapps to    hostname.database.schema.table

This way the applications can do a bit HA or distributed DB...

Neil Conway wrote:

>On Tue, 2003-02-25 at 22:44, Ed L. wrote:
>
>
>>And do I understand correctly the replication to be eventually
>>included will be an embedded syncronous replication solution based on
>>Postgres-R and the Spread GCS?
>>
>>
>
>No, I don't think that's set in stone (although I can't speak for the
>core team). While I think Postgres-R is promising, there might be room
>for additional replication implementations that cater to different sets
>of requirements.
>
>IMHO, eventually providing solutions for both synchronous and
>asynchronous replication would be a good idea.
>
>Cheers,
>
>Neil
>
>




Re: 7.4?

From
"Ed L."
Date:
On Wednesday February 26 2003 8:08, Tom Lane wrote:
> > I would've assumed an asyncronous solution would be far more
> > applicable for
>
> You're just showing bias in the other direction ;-).

Mea culpa.

> Back when I was working for Great Bridge and got to spend a fair
> amount of time at trade shows talking to potential customers, the
> thing we heard over and over again was that people wanted multiple
> servers for reliability/redundancy.  That goal seems to me to be
> best served by a symmetric multi-master configuration, which is
> difficult if not impossible to do with async replication.

I also share the objectives of reliability/redundancy.  My concern
with syncronous solutions in general is recoverability when one of
two masters fails.  Admittedly at the price of intervals of data
inconsistency between master and slave, async solutions can just pop
back online and "catch-up", thus the appeal.  In reading a little
more on PG-R, I understand the use of the Spread GCS would seem to
address that recoverability concern along with performance concerns.
Is that your understanding?

As an aside, ERserver looks credible, though the $10,000 pricetag and
closed source are somewhat of a barrier, so I hope an increasingly
useful open-source async solution can further emerge.

Ed

Re: 7.4?

From
Joe Tomcat
Date:
On Wed, 2003-02-26 at 07:08, Tom Lane wrote:
> Back when I was working for Great Bridge and got to spend a fair amount
> of time at trade shows talking to potential customers, the thing we
> heard over and over again was that people wanted multiple servers for
> reliability/redundancy.  That goal seems to me to be best served by a
> symmetric multi-master configuration, which is difficult if not
> impossible to do with async replication.

I'm glad to hear that PG is heading in that direction.  Think of it this
way: the entire reason we use databases instead of a mess of text files
is because of the benefits we get in terms of data consistency.  ACID
forms the foundation for a reliable service, whether it's financial
transactions or a chat room.  It is difficult or impossible to maintain
ACID in an async situation, I believe.

Sync is actually much more useful because it lets a business have a
cluster of servers without having to worry about what state things are
in.



Re: 7.4?

From
Richard Welty
Date:
On 24 Feb 2003 04:00:51 -0800 Joe Tomcat <tomcat@mobile.mp> wrote:
> Sync is actually much more useful because it lets a business have a
> cluster of servers without having to worry about what state things are
> in.

sync is more useful _if_ sync is what you need.

my current project needs async, sync wouldn't help me a damn bit.

richard
--
Richard Welty                                         rwelty@averillpark.net
Averill Park Networking                                         518-573-7592
              Unix, Linux, IP Network Engineering, Security

Re: 7.4?

From
"Shridhar Daithankar"
Date:
On 24 Feb 2003 at 15:53, Ericson Smith wrote:
> Currently our database is at about 15gigs. Over the period of a month,
> it grows to about 25gigs (10Gb wasted space). Every month we have a
> cleanup routine which involves copying the most actively updated tables
> to text, and importing the data again. We vacuum every night and analyze
> 4 times per day, but we're loath to do a VACUUM FULL because of the
> table locking issues (locking some of the tables would break the
> operation of some of our 24/7 systems), hence we prefer to stop the db
> about once per month, eat the downtime as scheduled (about 1.5 hours),
> and get back to business for the next 30 days again.

We ahd a discussion on this few days back and the solution might work as well
for you(apart from suggestions you have already received).

Instead of vacuum full on a table, backup the table to a dump file, drop it and
recreate it. It takes more efforts than simple vacuum full but may run much
faster if you have large amount of space to recover.

 Try it.


Bye
 Shridhar

--
"I'd crawl over an acre of 'Visual This++' and 'Integrated DevelopmentThat' to
get to gcc, Emacs, and gdb.  Thank you."(By Vance Petree, Virginia Power)


Re: 7.4?

From
Andreas Rust
Date:
At 08:07 27.02.03, you wrote:
>On 24 Feb 2003 at 15:53, Ericson Smith wrote:
> > Currently our database is at about 15gigs. Over the period of a month,
> > it grows to about 25gigs (10Gb wasted space). Every month we have a
> > cleanup routine which involves copying the most actively updated tables
> > to text, and importing the data again. We vacuum every night and analyze
> > 4 times per day, but we're loath to do a VACUUM FULL because of the
> > table locking issues (locking some of the tables would break the
> > operation of some of our 24/7 systems), hence we prefer to stop the db
> > about once per month, eat the downtime as scheduled (about 1.5 hours),
> > and get back to business for the next 30 days again.
>
>We ahd a discussion on this few days back and the solution might work as well
>for you(apart from suggestions you have already received).
>
>Instead of vacuum full on a table, backup the table to a dump file, drop
>it and
>recreate it. It takes more efforts than simple vacuum full but may run much
>faster if you have large amount of space to recover.
>
>  Try it.


It was me having this problem with our DB, although it only went to 1 gig
for some
3000 rows overall. So far, the problem is not really solved for me, since
vacuum full
simply takes far too long to clean up the DB. Disksize of this DB varies around
800 MB to 1 Gig and a vacuum full 'only' takes it down to 500 megs.
A complete dump and re-creation of the dbase creates a nice 120 megs DB.

Shouldnt a 'vacuum full' come close to this ? atleast not 4-5 times the size.

Our problems are caused by a popular (?) bannersystem, btw, which simply does
too many updates. (A few on each user request to the webserver).
(The very same bannersystem exists for MySQL and the table there is less
  than a megabyte. We switched to MySQL after one of the servers couldnt
stand the load
  anymore. Another Server is still running the pg version, but mainly for
testing purposes and
  to help out the dude who is porting it to pg ...)

I also want to add, that postgres' "contrib/vacuumlo" didnt change much on the
large DB and a load of changes on that bannersystem didn't do much either.

l8r


     Andreas Rust     -   webnova GmbH
     rust@webnova.de  -   www.webnova.de
     Tel:  +49 (0)234 - 912 96 10
     Fax:  +49 (0)234 - 912 96 15
+:----------------------------------------------------------:+
       Internet Solutions & Creative Design


Function example returning more then 1 value

From
"Roberto de Amorim"
Date:
I looked at
http://developer.postgresql.org/docs/postgres/plpgsql-examples.html
but there is not an example of function returning more then 1 value...

could anyone sand me an example of function returning more then 1 value
using PLPGSQL ? please

TIA

Roberto de amorim



Re: Function example returning more then 1 value

From
Darko Prenosil
Date:
On Thursday 27 February 2003 12:25, Roberto de Amorim wrote:
> I looked at
> http://developer.postgresql.org/docs/postgres/plpgsql-examples.html
> but there is not an example of function returning more then 1 value...
>
> could anyone sand me an example of function returning more then 1 value
> using PLPGSQL ? please
>
    You can't return more than one return value from function, but that
value can be of composite type.For example :"setof text" or "setof record" are
such types.

    See:
http://developer.postgresql.org/docs/postgres/plpgsql-control-structures.html
http://developer.postgresql.org/docs/postgres/xfunc.html


Regards !

Re: 7.4?

From
Andrew Sullivan
Date:
On Wed, Feb 26, 2003 at 02:41:10PM -0700, Ed L. wrote:

> I also share the objectives of reliability/redundancy.  My concern
> with syncronous solutions in general is recoverability when one of
> two masters fails.  Admittedly at the price of intervals of data
> inconsistency between master and slave, async solutions can just pop
> back online and "catch-up", thus the appeal.  In reading a little

It seems to me that this answer is only true if you can tolerate loss
or delay of transactions.  That is, if the order of transactions
matters, you really can't just make your former slave a master
without knowing that the failed master has sent everything to the
slave.

If order matters, then the opposite is true: because you know that
any master has all the data, you can just accept it when one master
goes away.  Of course, that requires a good program for adding new
replicated systems, which I guess is what Postgres-R is going to do.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: 7.4?

From
"scott.marlowe"
Date:
On Thu, 27 Feb 2003, Shridhar Daithankar wrote:

> On 24 Feb 2003 at 15:53, Ericson Smith wrote:
> > Currently our database is at about 15gigs. Over the period of a month,
> > it grows to about 25gigs (10Gb wasted space). Every month we have a
> > cleanup routine which involves copying the most actively updated tables
> > to text, and importing the data again. We vacuum every night and analyze
> > 4 times per day, but we're loath to do a VACUUM FULL because of the
> > table locking issues (locking some of the tables would break the
> > operation of some of our 24/7 systems), hence we prefer to stop the db
> > about once per month, eat the downtime as scheduled (about 1.5 hours),
> > and get back to business for the next 30 days again.
>
> We ahd a discussion on this few days back and the solution might work as well
> for you(apart from suggestions you have already received).
>
> Instead of vacuum full on a table, backup the table to a dump file, drop it and
> recreate it. It takes more efforts than simple vacuum full but may run much
> faster if you have large amount of space to recover.

Another option is to do something like:

begin;
select * into temp_table from bigtable;
delete from big_table;
insert into big_table (select * from temp_table);
commit;

This way your table is online while you're doing this, and can still be
selected by various clients without interruption.


Re: 7.4?

From
"Ed L."
Date:
On Thursday February 27 2003 6:36, Andrew Sullivan wrote:
> On Wed, Feb 26, 2003 at 02:41:10PM -0700, Ed L. wrote:
> > I also share the objectives of reliability/redundancy.  My
> > concern with syncronous solutions in general is recoverability
> > when one of two masters fails.  Admittedly at the price of
> > intervals of data inconsistency between master and slave, async
> > solutions can just pop back online and "catch-up", thus the
> > appeal.  In reading a little
>
> It seems to me that this answer is only true if you can tolerate
> loss or delay of transactions.  That is, if the order of
> transactions matters, you really can't just make your former slave
> a master without knowing that the failed master has sent everything
> to the slave.

Agreed.  In our case, we presently have _no_ replication solution nor
do we have a true file system snapshot capability e.g. NetApp.  So,
in the event of the untimely total demise of the primary server, the
timespan of data loss equals time since the last dump that made it
off the server.  That typically amounts to _hours_.  With async
replication to a spare server, that couple of hours of lost data
would seem to be reduced to seconds.  That's not ideal by any
stretch, but is a monstrous improvement.  I'm assuming eRServer,
rserv, or DBMirror maintains a proper transaction order, even if it's
incomplete.

> If order matters, then the opposite is true: because you know that
> any master has all the data, you can just accept it when one master
> goes away.  Of course, that requires a good program for adding new
> replicated systems, which I guess is what Postgres-R is going to
> do.

Agreed.  It also requires a good program for dealing with failed
masters and dealing with sync performance issues (2-phase commit).
Sounds like PG-R + Spread is tackling that, too.  I am learning that,
if PG-R can work as advertised, it removes all my concerns about a
syncronous system.

My current thinking is to implement simple async master/slave now,
with the acknowledged potential data loss (albeit much smaller), and
migrate to sync multi-master if/when PG-R comes online.  I had little
success with rserv, but DBMirror worked ok.  I'm enhancing DBMirror
up to work better for our environment.

Ed


DBMirror mailing list (was Re: 7.4?)

From
Richard Welty
Date:
On Thu, 27 Feb 2003 12:00:50 -0700 "Ed L." <pgsql@bluepolka.net> wrote:
>  I had little
> success with rserv, but DBMirror worked ok.  I'm enhancing DBMirror
> up to work better for our environment.

this actually brings up a question:

is there currently a mailing list for DBMirror users? i'm about to start
using it, and a place to discuss it with other users might be a useful
subgroup.

if not, i can certainly set one up on my server, although there might be
more appropriate places for one to be set up (e.g., on postgresql.org)

richard
--
Richard Welty                                         rwelty@averillpark.net
Averill Park Networking                                         518-573-7592
              Unix, Linux, IP Network Engineering, Security

Re: 7.4?

From
Andrew Sullivan
Date:
On Thu, Feb 27, 2003 at 12:00:50PM -0700, Ed L. wrote:
> stretch, but is a monstrous improvement.  I'm assuming eRServer,
> rserv, or DBMirror maintains a proper transaction order, even if it's
> incomplete.

I dunno about dbmirror, but rserv and its bigger cousin both actually
apply the current-as-of-snapshot version of the row (which means that
if you have multiple changes to the same row, you needn't go through
all the iterations when applying the snapshot).  I presume the same
is true of dbmirror, since it relies on the primary key.

> Sounds like PG-R + Spread is tackling that, too.  I am learning that,
> if PG-R can work as advertised, it removes all my concerns about a
> syncronous system.

Yes, if it works as advertised, it'd be a _mighty sweet_ piece of
technology.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: 7.4?

From
"Ed L."
Date:
On Thursday February 27 2003 12:57, Andrew Sullivan wrote:
>
> I dunno about dbmirror, but rserv and its bigger cousin both
> actually apply the current-as-of-snapshot version of the row (which
> means that if you have multiple changes to the same row, you
> needn't go through all the iterations when applying the snapshot).
> I presume the same is true of dbmirror, since it relies on the
> primary key.

Unfortunately, dbmirror does go through all the iterations, even if
there is no net change.  That current-as-of-snapshot capability you
describe would be a very useful enhancement.

Ed


Re: DBMirror mailing list (was Re: 7.4?)

From
"Ed L."
Date:
On Thursday February 27 2003 12:56, Richard Welty wrote:
>
> is there currently a mailing list for DBMirror users? i'm about to
> start using it, and a place to discuss it with other users might be
> a useful subgroup.

No comment on a new mailing list, but I'm happy to collaborate if
there is interest.  The key changes in which I'm presently interested
are:

    * master/slave port specification (done);
    * configurable sync delay (done);
    * "current-as-of-snapshot" described by Andrew Sullivan;
    * tools for easy setup and activation;
    * multi-slave;

Ed



Re: 7.4?

From
Andrew Sullivan
Date:
On Thu, Feb 27, 2003 at 02:21:23PM -0700, Ed L. wrote:
>
> Unfortunately, dbmirror does go through all the iterations, even if

So does dbmirror keep a copy of the row somewhere?  Doesn't that add
a lot to i/o?

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: DBMirror mailing list (was Re: 7.4?)

From
Andrew Sullivan
Date:
On Thu, Feb 27, 2003 at 02:56:33PM -0500, Richard Welty wrote:

> is there currently a mailing list for DBMirror users? i'm about to start

There has been some discussion about it on the replication list.  The
replication list is pretty low-traffic, and it's a natural place to
discuss it.

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: 7.4?

From
"Ed L."
Date:
On Thursday February 27 2003 2:21, Ed L. wrote:
> On Thursday February 27 2003 12:57, Andrew Sullivan wrote:
> > I dunno about dbmirror, but rserv and its bigger cousin both
> > actually apply the current-as-of-snapshot version of the row
> > (which means that if you have multiple changes to the same row,
> > you needn't go through all the iterations when applying the
> > snapshot). I presume the same is true of dbmirror, since it
> > relies on the primary key.

By the way, rserv failed precisely in this case for me as I mentioned
in a previous recent post.

Ed


Re: 7.4?

From
"Ed L."
Date:
On Thursday February 27 2003 3:28, Andrew Sullivan wrote:
> On Thu, Feb 27, 2003 at 02:21:23PM -0700, Ed L. wrote:
> > Unfortunately, dbmirror does go through all the iterations, even
> > if
>
> So does dbmirror keep a copy of the row somewhere?  Doesn't that
> add a lot to i/o?

Yes and yes, it would seem so.  It could be a significant performance
issue for a database with lots of updates in a short amount of time.
The "current-as-of-snapshot" approach would be a valuable
enhancement.

Ed


Re: 7.4?

From
Peter Childs
Date:
On Thu, 27 Feb 2003, Andrew Sullivan wrote:

> On Thu, Feb 27, 2003 at 02:21:23PM -0700, Ed L. wrote:
> >
> > Unfortunately, dbmirror does go through all the iterations, even if
>
> So does dbmirror keep a copy of the row somewhere?  Doesn't that add
> a lot to i/o?
>
> A
>
>
    Ok we seam to have quite a lot of talk about replication options
here.
    I need to implement one sooner or later....
    Which is best seams to be on requirments and not much else. So
perhaps a list of whats currently available, its requirements and what it
is best for would be good on the web site. Here are my requirements.

1> MultiMaster (Database involves quite a lot of writes)
2> 24 x 7 operation so one server must be able to cope while the other
vacuums, backups etc,
3> Consistant all machines that are up must look the same when in master
usage.

    The problem as far as I can see with sycronse systems is that they
can't cope with down time and that in my book is the primary reason for
having replication.

Peter Childs
P.S. A Hot Spare might actually be the best answer.... `


Re: 7.4?

From
Neil Conway
Date:
On Fri, 2003-02-28 at 04:49, Peter Childs wrote:
> The problem as far as I can see with sycronse systems is that they
> can't cope with down time

Uh, why can't they?

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC




Re: 7.4?

From
"Ed L."
Date:
On Friday February 28 2003 2:49, Peter Childs wrote:
>
>     The problem as far as I can see with sycronse systems is that they
> can't cope with down time and that in my book is the primary reason
> for having replication.

The online Postgres-R docs discuss the application of the Spread GCS
to deal with traditional disadvantages with syncronous systems.

Ed


Re: 7.4?

From
Andrew Sullivan
Date:
On Fri, Feb 28, 2003 at 09:49:08AM +0000, Peter Childs wrote:
> 1> MultiMaster (Database involves quite a lot of writes)

There aren't any that do this right now.  Define "quite a lot".

A

--
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110


Re: 7.4?

From
"Luc Martienau"
Date:
>
> >
> >Do you guys have any tentative estimates about when 7.4 is going to get
released?
> >What is the timeframe? Also, what is going to be there that is not in
7.3?
> >I am currently on 7.2, and trying to find out whether it makes sense to
upgrade to 7.3 now or to
> wait for 7.4 and go right there...
> >


Hello
Am I wrrong if I said that with 7.3.3 you can passed up to 32 parameters to
a function and only 16 with 7.2.?

Regards
Luc
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)



Re: 7.4?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Neil Conway writes:
> >> I'd be quite surprised to see this in 7.4. Not that I wouldn't love to
> >> have someone contribute it -- I just wouldn't bet on it being in 7.4 if
> >> the beta date is around the middle of April.
>
> > When someone says that beta is planned April-ish, that means beta will be
> > in June and the final release will be in September.  Mark my words.
>
> If all three of these changes (Windows port, pitr, replication) get in
> before feature freeze, I wouldn't want to bet that final will be any
> sooner than that --- we'll have lots of testing to do.
>
> But we *will* freeze 7.4 features in April, and at the rate work appears
> to be progressing, I wouldn't want to bet that any of these features
> will be in by then ;-).  If they don't make the cut, 7.4 final will
> probably be a lot sooner than September.

Where did you get the April date from?  I didn't hear any discussion
about that.  I personally was thinking of June 1.

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

Re: 7.4?

From
Bruce Momjian
Date:
You might want to look at my replication talk:

    http://candle.pha.pa.us/main/writings/pgsql/replication.pdf

Basically, single-master uses async because it is faster, but when you
need multimaster, you usually need sync or a Postgres-R-type approach.

Seems there too may replication needs, so even Postgres-R will remain a
plugin option for PostgreSQL, like the other replication solutions.

---------------------------------------------------------------------------

Herv� Piedvache wrote:
> Le Mercredi 26 F?vrier 2003 07:52, Tom Lane a ?crit :
> > Neil Conway <neilc@samurai.com> writes:
> > > On Tue, 2003-02-25 at 22:44, Ed L. wrote:
> > >> And do I understand correctly the replication to be eventually
> > >> included will be an embedded syncronous replication solution based on
> > >> Postgres-R and the Spread GCS?
> > >
> > > No, I don't think that's set in stone (although I can't speak for the
> > > core team). While I think Postgres-R is promising, there might be room
> > > for additional replication implementations that cater to different sets
> > > of requirements.
> >
> > There absolutely *is* room for multiple replication implementations.
> > AFAICS there's no one-size-fits-all approach.  I did and still do like
> > Postgres-R as a pretty useful approach, but it should not be mistaken
> > for The One True Path.
> >
> > Also, there are nontrivial licensing issues involved.  The PG-R design
> > depends on an underlying "group communication" system, which is a
> > nontrivial bit of software that none of the core team wants to rewrite.
> > But none of the available GC systems are BSD-license open source.  We
> > had had some hopes of getting Spread to offer BSD terms, but that seems
> > to have fallen through.  So right now, PG-R is on the outside looking
> > in, as far as inclusion in the core distribution goes :-(
> >
> >             regards, tom lane
>
> You mean the PG-R project will no be included in the PostgreSQL project
> unless someone rewrite the Spread GCS concept or similar system in a BSD
> licence ?
>
> What a bad news for the community ... ! :o(
>
> PG-R seems to be the best integrated solution of the moment ... Still a lot
> of work ... but Darren and others are making a real good job !
>
> DBMirror or rserv (commercial application) seems to be only triggers, and
> little demon not included in PostgreSQL system ... as PG-R is ...
>
> PostgreSQL really need an official Replication solution to be definitively
> secured in a productive environnement ... and I think I'm not the only one
> thinking like that ... looking the survey of Postgres.org web site :
> http://www.postgresql.org/survey.php?View=1&SurveyID=9
> --
> Herv? Piedvache
>
> Elma Ing?nierie Informatique
> 6 rue du Faubourg Saint-Honor?
> F-75008 - Paris - France
> Tel. 33-144949901
> fax. 33-144949902
>

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

Re: 7.4?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> But we *will* freeze 7.4 features in April, and at the rate work appears
>> to be progressing, I wouldn't want to bet that any of these features
>> will be in by then ;-).  If they don't make the cut, 7.4 final will
>> probably be a lot sooner than September.

> Where did you get the April date from?  I didn't hear any discussion
> about that.  I personally was thinking of June 1.

We hadn't actually set a date yet, but I had been thinking end of April.

The point stands either way --- if there's any progress being made on
any of those features, it's not visible from where I sit.

            regards, tom lane

Re: 7.4?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Neil Conway writes:
> >> I'd be quite surprised to see this in 7.4. Not that I wouldn't love to
> >> have someone contribute it -- I just wouldn't bet on it being in 7.4 if
> >> the beta date is around the middle of April.
>
> > When someone says that beta is planned April-ish, that means beta will be
> > in June and the final release will be in September.  Mark my words.
>
> If all three of these changes (Windows port, pitr, replication) get in
> before feature freeze, I wouldn't want to bet that final will be any
> sooner than that --- we'll have lots of testing to do.
>
> But we *will* freeze 7.4 features in April, and at the rate work appears
> to be progressing, I wouldn't want to bet that any of these features
> will be in by then ;-).  If they don't make the cut, 7.4 final will
> probably be a lot sooner than September.

Also, as discussed in 7.3, I vote against a feature freeze that is
significantly earlier (>2 weeks) from the start of beta.  We did that
for 7.2, and it paralized the end of the developement period.

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

Re: 7.4?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> But we *will* freeze 7.4 features in April, and at the rate work appears
> >> to be progressing, I wouldn't want to bet that any of these features
> >> will be in by then ;-).  If they don't make the cut, 7.4 final will
> >> probably be a lot sooner than September.
>
> > Where did you get the April date from?  I didn't hear any discussion
> > about that.  I personally was thinking of June 1.
>
> We hadn't actually set a date yet, but I had been thinking end of April.
>
> The point stands either way --- if there's any progress being made on
> any of those features, it's not visible from where I sit.

I have the Win32 port planned for March for me. I haven't talked to
Patrick about PITR (added him to CC), but maybe he would like to chime in.
I haven't heard Postgres-R hooks, which is where we are now in the plan,
are ready to go.

So you were thinking of beta for May 1?

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

Re: 7.4?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, as discussed in 7.3, I vote against a feature freeze that is
> significantly earlier (>2 weeks) from the start of beta.  We did that
> for 7.2, and it paralized the end of the developement period.

The problem there was not the feature freeze, it was that we kept
slipping the beta date while we waited around for certain items
to get done.  The lesson I take away from the past couple releases
is that you set a target beta date and then stick to it; features
that aren't in on time don't get extensions.

In other words, we shouldn't be waving our hands and saying "there's
still plenty of time for these things to happen for 7.4".  There's
not, unless we go back to the previous philosophy of "we'll slip
the release as long as it takes for something to happen".  I think
it's past time to light a fire under the folks who are supposedly
doing these items.

            regards, tom lane

Re: 7.4?

From
Neil Conway
Date:
On Thu, 2003-03-06 at 11:50, Bruce Momjian wrote:
> So you were thinking of beta for May 1?

Rather than picking an arbitrary date for the beta, wouldn't it make
more sense to simply put out the beta when a particular set of features
are finished (say, Win32 + PITR + ...)

The potential downside is that the development period will drag on and
on, waiting for the delinquent features to be implemented.

The upside is that when we actually do make the release, we'll be sure
that we have enough features to justify an upgrade. As has been often
remarked, upgrading PostgreSQL is somewhat painful. I'd much rather make
periodic releases with major feature improvements than more frequent,
incremental releases -- because the initdb/reload pain will be the same
in either case.

Anyway, just throwing it out there... :-)

Cheers,

Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC




Re: 7.4?

From
Bruce Momjian
Date:
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Also, as discussed in 7.3, I vote against a feature freeze that is
> > significantly earlier (>2 weeks) from the start of beta.  We did that
> > for 7.2, and it paralized the end of the developement period.
>
> The problem there was not the feature freeze, it was that we kept
> slipping the beta date while we waited around for certain items
> to get done.  The lesson I take away from the past couple releases
> is that you set a target beta date and then stick to it; features
> that aren't in on time don't get extensions.

OK, let's follow that logic.  Do we have enough to justify a release
without any of those features?  I don't think so.

> In other words, we shouldn't be waving our hands and saying "there's
> still plenty of time for these things to happen for 7.4".  There's
> not, unless we go back to the previous philosophy of "we'll slip
> the release as long as it takes for something to happen".  I think
> it's past time to light a fire under the folks who are supposedly
> doing these items.

I do remember in 7.2 an attempt to come to a controlled slowdown 4-6
weeks before we even planned on starting beta.  The later problem was
that beta start was one month late, and then dragged, so there were
multiple problems with that release:  stop features late July, early
August; beta scheduled September 1, started October 1; then dragged
waiting for fixes rather than backing out features.

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

Re: 7.4?

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> The problem there was not the feature freeze, it was that we kept
>> slipping the beta date while we waited around for certain items
>> to get done.  The lesson I take away from the past couple releases
>> is that you set a target beta date and then stick to it; features
>> that aren't in on time don't get extensions.

> OK, let's follow that logic.  Do we have enough to justify a release
> without any of those features?  I don't think so.

Sure we do.  A quick scan of the CVS logs reminds me that we have
already done a bunch of stuff:

btree index space recycling
free-space-map management improvements
IN, NOT IN via hashtables and/or joins
hash-based aggregation
merge/hash on expressions more complex than simple Vars
deduction of equality on expressions other than simple Vars
hash joins can use more than one join key
smarter planning of outer joins
join syntax doesn't necessarily constrain plan
smarter planning of nestloop inner indexscans with multiple outer relations
new regex library
domain CHECK constraints
ALTER DOMAIN
grant options, cascaded revoke
print more information about deadlocks
information schema
read-only transactions
first-class COALESCE and NULLIF constructs (no duplicate evaluation)
IPv6 connections
Simple SQL functions expand into inline expressions
Eliminate memory leaks in SQL functions
CLUSTER ALL
transaction-safe TRUNCATE
FOR EACH STATEMENT triggers
ON COMMIT PRESERVE/DELETE ROWS for temp tables

(plus lots more minor things) --- and we still have a couple months of
development left.  I don't see a good reason to delay releasing these
features if other ones aren't ready.

            regards, tom lane

Re: 7.4?

From
Bruce Momjian
Date:
Yes, those are nice, but they aren't killer features like Win32 or PITR.
I was hoping for one or two killer features for 7.4.

Considering a feature freeze two weeks before beta, we are looking at
six weeks left.  I don't know that I can do Win32 in six weeks.  If we
go for June 1, we are looking at ten weeks.

Can I get comments from others?

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> The problem there was not the feature freeze, it was that we kept
> >> slipping the beta date while we waited around for certain items
> >> to get done.  The lesson I take away from the past couple releases
> >> is that you set a target beta date and then stick to it; features
> >> that aren't in on time don't get extensions.
>
> > OK, let's follow that logic.  Do we have enough to justify a release
> > without any of those features?  I don't think so.
>
> Sure we do.  A quick scan of the CVS logs reminds me that we have
> already done a bunch of stuff:
>
> btree index space recycling
> free-space-map management improvements
> IN, NOT IN via hashtables and/or joins
> hash-based aggregation
> merge/hash on expressions more complex than simple Vars
> deduction of equality on expressions other than simple Vars
> hash joins can use more than one join key
> smarter planning of outer joins
> join syntax doesn't necessarily constrain plan
> smarter planning of nestloop inner indexscans with multiple outer relations
> new regex library
> domain CHECK constraints
> ALTER DOMAIN
> grant options, cascaded revoke
> print more information about deadlocks
> information schema
> read-only transactions
> first-class COALESCE and NULLIF constructs (no duplicate evaluation)
> IPv6 connections
> Simple SQL functions expand into inline expressions
> Eliminate memory leaks in SQL functions
> CLUSTER ALL
> transaction-safe TRUNCATE
> FOR EACH STATEMENT triggers
> ON COMMIT PRESERVE/DELETE ROWS for temp tables
>
> (plus lots more minor things) --- and we still have a couple months of
> development left.  I don't see a good reason to delay releasing these
> features if other ones aren't ready.
>
>             regards, tom lane
>

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

Re: 7.4?

From
Patrick Macdonald
Date:
Hi Bruce,

PITR is still on my plate although I have not had much time to work on
it.  There was a slight shift of focus regarding PostgreSQL - Red Hat
Edition (Red Hat Database) and that consumed the majority of my time
over the past two months.  The good news is that time has been cleared
off my schedule for this work.  Tom is coming up at the end of March
and I hope to have a limited walkthrough at that time.

Cheers,
Patrick

Bruce Momjian wrote:
> Tom Lane wrote:
>
>>Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>
>>>Tom Lane wrote:
>>>
>>>>But we *will* freeze 7.4 features in April, and at the rate work appears
>>>>to be progressing, I wouldn't want to bet that any of these features
>>>>will be in by then ;-).  If they don't make the cut, 7.4 final will
>>>>probably be a lot sooner than September.
>>>
>>>Where did you get the April date from?  I didn't hear any discussion
>>>about that.  I personally was thinking of June 1.
>>
>>We hadn't actually set a date yet, but I had been thinking end of April.
>>
>>The point stands either way --- if there's any progress being made on
>>any of those features, it's not visible from where I sit.
>
>
> I have the Win32 port planned for March for me. I haven't talked to
> Patrick about PITR (added him to CC), but maybe he would like to chime in.
> I haven't heard Postgres-R hooks, which is where we are now in the plan,
> are ready to go.
>
> So you were thinking of beta for May 1?
>



Re: 7.4?

From
Robert Treat
Date:
On Thu, 2003-03-06 at 13:10, Bruce Momjian wrote:
>
> Yes, those are nice, but they aren't killer features like Win32 or PITR.
> I was hoping for one or two killer features for 7.4.
>
> Considering a feature freeze two weeks before beta, we are looking at
> six weeks left.  I don't know that I can do Win32 in six weeks.  If we
> go for June 1, we are looking at ten weeks.
>
> Can I get comments from others?
>

I really like some of the features Tom listed, but I tend to agree with
Bruce on this one; none of those features are terribly compelling. We
could release without win32 or replication, but those are the "biguns",
and without one of those I think 7.4 will be less than exciting. I sure
part of Tom's concern is what happens when June 1st rolls around and
win32/replication still isn't ready? Perhaps the official feature freeze
date should be kept as May 1st, at which time we'll reevaluate where
win32/replication stand and make a decision at that time. This way no
one should be taken by surprise if feature freeze actually sticks on May
1st, and we'll know if we're looking at extending development by a
couple of weeks for a killer app, or if the features are more than a
month off we can decide to go on without them.

Robert Treat


Re: 7.4?

From
Tom Lane
Date:
Neil Conway <neilc@samurai.com> writes:
> On Thu, 2003-03-06 at 11:50, Bruce Momjian wrote:
>> So you were thinking of beta for May 1?

> Rather than picking an arbitrary date for the beta, wouldn't it make
> more sense to simply put out the beta when a particular set of features
> are finished (say, Win32 + PITR + ...)

We did that for 7.1, and again in 7.2; and it was a bad mistake both
times, because we found ourselves in a state where "it's almost done
except X" --- and no one except the person working on X could really
do any further development.

For 7.3 we agreed to set a firm feature-freeze cutoff date well in
advance.  That worked a *lot* better, and I'd like to stick with that
approach.

I don't actually much care whether the cutoff is May 1 or June 1 or
whatever.  But I want it set in advance, and stuck to, so that people
can plan their own efforts without wondering what will be happening.

            regards, tom lane

Re: 7.4?

From
Bruce Momjian
Date:
Yes, the big trick is to set the deadline weeks before, and if you need
to delay, you do it long before the deadline arrives.  Meaning, if you
want to deadline May 1, you should decide that April 1, and if you
decide to change your mind, you should jump another month, so decide by
mid-May if June 1 is going to work.

---------------------------------------------------------------------------

Tom Lane wrote:
> Neil Conway <neilc@samurai.com> writes:
> > On Thu, 2003-03-06 at 11:50, Bruce Momjian wrote:
> >> So you were thinking of beta for May 1?
>
> > Rather than picking an arbitrary date for the beta, wouldn't it make
> > more sense to simply put out the beta when a particular set of features
> > are finished (say, Win32 + PITR + ...)
>
> We did that for 7.1, and again in 7.2; and it was a bad mistake both
> times, because we found ourselves in a state where "it's almost done
> except X" --- and no one except the person working on X could really
> do any further development.
>
> For 7.3 we agreed to set a firm feature-freeze cutoff date well in
> advance.  That worked a *lot* better, and I'd like to stick with that
> approach.
>
> I don't actually much care whether the cutoff is May 1 or June 1 or
> whatever.  But I want it set in advance, and stuck to, so that people
> can plan their own efforts without wondering what will be happening.
>
>             regards, tom lane
>

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

Re: 7.4?

From
Bruce Momjian
Date:
Patrick Macdonald wrote:
> Hi Bruce,
>
> PITR is still on my plate although I have not had much time to work on
> it.  There was a slight shift of focus regarding PostgreSQL - Red Hat
> Edition (Red Hat Database) and that consumed the majority of my time
> over the past two months.  The good news is that time has been cleared
> off my schedule for this work.  Tom is coming up at the end of March
> and I hope to have a limited walkthrough at that time.

Patrick, what does "limited walkthrough" mean?  Code done or coding
ideas?

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

Re: 7.4?

From
Patrick Macdonald
Date:
Bruce,

It means I'll walk through what I have at the time.  The code won't be
complete but the intent is to identify what's missing.

Patrick

Bruce Momjian wrote:
>
> Patrick Macdonald wrote:
> > Hi Bruce,
> >
> > PITR is still on my plate although I have not had much time to work on
> > it.  There was a slight shift of focus regarding PostgreSQL - Red Hat
> > Edition (Red Hat Database) and that consumed the majority of my time
> > over the past two months.  The good news is that time has been cleared
> > off my schedule for this work.  Tom is coming up at the end of March
> > and I hope to have a limited walkthrough at that time.
>
> Patrick, what does "limited walkthrough" mean?  Code done or coding
> ideas?
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073