7.4RC1 planned for Monday

--On Thursday, October 30, 2003 18:43:25 -0500 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

Barring the discovery of any major new bugs, the core committee has
agreed to release 7.4RC1 on Monday. Time to get those last-minute
fixes in place.

I currently have the following issues on my radar screen:

Force GRANT/REVOKE by superuser to act as though owner of object?
Change libpgtcl to use ByteArray for lo_read/lo_write (ljb's patch)
Add option for parallelism limit in make check (Andrew Dunstan's patch)
rule/foreign key interaction reported by Michele Bendazzoli

plus various minor documentation fixes. Not much there...

BTW, 7.4 final will be as early as the following Monday if no problems
are detected. We will decide on a week-to-week basis whether we are
ready to release final or not.

Is there any possibility of getting some help to detect the SCO UnixWare
7.1.3UP3 compiler to allow us to conditionally remove the -Kno_host for
the fixed compiler into 7.4?

It would be a good thing. (UP3 came out yesterday).

LER

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Hello,

I know I will probably be flamed into oblivion for this but I would
like to make a suggestion about
the upcoming release.

What if we delayed until the end of the year?

The two reasons that I can come up with are:

1. The irritating (but work around capable) bigint index issue.
2. More importantly the recent potential discovery by Jan on vacuum.

I have several high end users that are really beating their heads
against the wall with even lazy vacuum
because of how brutal it can be on the system. If we could make vacuum a
little less harsh it could be
a large boon.

If I am totally off my rocker, so be it but if we were to hit the
streets with 7.4 and a vacuum that was 70% (ex)
less brutal on the machine it would be a pretty significant statement.

Yes all the other fixes are great and cool.

Sincerely,

Joshua D. Drake

Tom Lane wrote:

Barring the discovery of any major new bugs, the core committee has
agreed to release 7.4RC1 on Monday. Time to get those last-minute
fixes in place.

I currently have the following issues on my radar screen:

Force GRANT/REVOKE by superuser to act as though owner of object?
Change libpgtcl to use ByteArray for lo_read/lo_write (ljb's patch)
Add option for parallelism limit in make check (Andrew Dunstan's patch)
rule/foreign key interaction reported by Michele Bendazzoli

plus various minor documentation fixes. Not much there...

BTW, 7.4 final will be as early as the following Monday if no problems
are detected. We will decide on a week-to-week basis whether we are
ready to release final or not.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org

On Thu, 30 Oct 2003, Joshua D. Drake wrote:

Hello,

I know I will probably be flamed into oblivion for this but I would
like to make a suggestion about
the upcoming release.

What if we delayed until the end of the year?

The two reasons that I can come up with are:

1. The irritating (but work around capable) bigint index issue.
2. More importantly the recent potential discovery by Jan on vacuum.

I have several high end users that are really beating their heads
against the wall with even lazy vacuum
because of how brutal it can be on the system. If we could make vacuum a
little less harsh it could be
a large boon.

Are these folks for whom the autovacuum daemon provides no relief?

I think it's too late in the release cycle to put everything on hold,
especially with no known fix in sight (for bigint at least.)

"Joshua D. Drake" <jd@commandprompt.com> writes:

What if we delayed until the end of the year?

Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on how to fix the integer-index issues, and
I'm not willing to hold 7.4 (or even 7.5) hostage to finding one.

Sooner or later you have to say "this release is done, let's ship it".
It's way too late to go back into invention mode for 7.4.

regards, tom lane

Sooner or later you have to say "this release is done, let's ship it".
It's way too late to go back into invention mode for 7.4.

I agree with the argument. It is just that the Vacuum one... well is
very tempting.
On the 7.5 cycle though... I thought 7.5 was basically for win32?

Sincerely,

Joshua Drake

regards, tom lane

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org

"scott.marlowe" <scott.marlowe@ihs.com> writes:

Are these folks for whom the autovacuum daemon provides no relief?

If I understood correctly, Josh was complaining about VACUUM sucking too
much of his disk bandwidth. autovacuum wouldn't help that --- in fact
would likely make it worse, since a cron-driven vacuum script can at
least be scheduled for low-load times of day. autovacuum is likely to
kick in at the least convenient times.

However, we have at this point got only speculative solutions to the
too-much-bandwidth problem. If we had something ready to go today,
I'd be as willing as the next guy to cram it into 7.4. I'm not willing
to go back into development mode for 7.4, though.

regards, tom lane

If I understood correctly, Josh was complaining about VACUUM sucking too

much of his disk bandwidth. autovacuum wouldn't help that --- in fact
would likely make it worse, since a cron-driven vacuum script can at
least be scheduled for low-load times of day. autovacuum is likely to
kick in at the least convenient times.

Exactly!

However, we have at this point got only speculative solutions to the
too-much-bandwidth problem. If we had something ready to go today,
I'd be as willing as the next guy to cram it into 7.4. I'm not willing
to go back into development mode for 7.4, though.

regards, tom lane

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org

Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on how to fix the integer-index issues, and
I'm not willing to hold 7.4 (or even 7.5) hostage to finding one.

The idea of very short release cycle for 7.5 is interesting. What is
the core's decision for point-in-time-recovery? Maybe the decision is
7.5 does not include point-in-time-recovery?
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii@sra.co.jp> writes:

The idea of very short release cycle for 7.5 is interesting. What is
the core's decision for point-in-time-recovery? Maybe the decision is
7.5 does not include point-in-time-recovery?

We'd like to have it in 7.5. Whether it will get done in time is
impossible to predict at this point...

regards, tom lane

On Thu, Oct 30, 2003 at 09:08:43PM -0400, Tom Lane wrote:

Barring the discovery of any major new bugs, the core committee has
agreed to release 7.4RC1 on Monday. Time to get those last-minute
fixes in place.

I currently have the following issues on my radar screen:

Force GRANT/REVOKE by superuser to act as though owner of object?
Change libpgtcl to use ByteArray for lo_read/lo_write (ljb's patch)
Add option for parallelism limit in make check (Andrew Dunstan's
patch) rule/foreign key interaction reported by Michele Bendazzoli

plus various minor documentation fixes. Not much there...

BTW, 7.4 final will be as early as the following Monday if no
problems are detected. We will decide on a week-to-week basis
whether we are ready to release final or not.

Any chance of putting up a torrent for it? I'd be happy to host, but
I'd have to get the link on the downloads page somehow :)

Cheers,
D
--
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100 cell: +1 415 235 3778

A rising tide sinks small boats, especially when the guys in the big
boats make sure they're anchored down.

On Thu, 30 Oct 2003, Tom Lane wrote:

rule/foreign key interaction reported by Michele Bendazzoli

In the interests of disclosure, if the case in question for the rule
fails, almost certainly deferred fk constraints will as well which I
think makes this a must fix for 7.4 and is another push to getting a
7.3.5.

On Thu, 30 Oct 2003, Joshua D. Drake wrote:

Sooner or later you have to say "this release is done, let's ship it".
It's way too late to go back into invention mode for 7.4.

I agree with the argument. It is just that the Vacuum one... well is
very tempting.
On the 7.5 cycle though... I thought 7.5 was basically for win32?

Nope, it is *hoped* that v7.5 will include win32 ...

On Fri, 31 Oct 2003, Tatsuo Ishii wrote:

Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on how to fix the integer-index issues, and
I'm not willing to hold 7.4 (or even 7.5) hostage to finding one.

The idea of very short release cycle for 7.5 is interesting. What is
the core's decision for point-in-time-recovery? Maybe the decision is
7.5 does not include point-in-time-recovery?

Does anyone have anything ready to put into CVS as soon as we start v7.5,
or shortly afterwards?

On Thu, 30 Oct 2003, David Fetter wrote:

On Thu, Oct 30, 2003 at 09:08:43PM -0400, Tom Lane wrote:

Barring the discovery of any major new bugs, the core committee has
agreed to release 7.4RC1 on Monday. Time to get those last-minute
fixes in place.

I currently have the following issues on my radar screen:

Force GRANT/REVOKE by superuser to act as though owner of object?
Change libpgtcl to use ByteArray for lo_read/lo_write (ljb's patch)
Add option for parallelism limit in make check (Andrew Dunstan's
patch) rule/foreign key interaction reported by Michele Bendazzoli

plus various minor documentation fixes. Not much there...

BTW, 7.4 final will be as early as the following Monday if no
problems are detected. We will decide on a week-to-week basis
whether we are ready to release final or not.

Any chance of putting up a torrent for it? I'd be happy to host, but
I'd have to get the link on the downloads page somehow :)

Put up a what ... ?

"Marc G. Fournier" <scrappy@postgresql.org> writes:

On Thu, 30 Oct 2003, David Fetter wrote:

Any chance of putting up a torrent for it? I'd be happy to host, but
I'd have to get the link on the downloads page somehow :)

Put up a what ... ?

Google for "BitTorrent". It's a pretty darn cool app but I don't
think the PG source tarball is really big enough to be worth the
trouble... It's great for things like CD images though.

-Doug

Marc G. Fournier wrote:

On Fri, 31 Oct 2003, Tatsuo Ishii wrote:

Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on how to fix the integer-index issues, and
I'm not willing to hold 7.4 (or even 7.5) hostage to finding one.

The idea of very short release cycle for 7.5 is interesting. What is
the core's decision for point-in-time-recovery? Maybe the decision is
7.5 does not include point-in-time-recovery?

Does anyone have anything ready to put into CVS as soon as we start v7.5,
or shortly afterwards?

Well, I have patches2:

http:/momjian.postgresql.org/cgi-bin/pgpatches2

There are a few things ready for application in there, plus other items
to start work on.

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

I meant related to PITR? :)

On Thu, 30 Oct 2003, Bruce Momjian wrote:

Does anyone have anything ready to put into CVS as soon as we start v7.5,
or shortly afterwards?

Check bruce's 7.5 patches list (can't remember the address though :) )

I have this COMMENT ON thing ready to go, except for this darn taking in
unsigned ints from the parser business that I haven't had any suggests
for :P

Chris

Oh, sorry, only read your part --- I have not heard anything about PITR
from Patrick. I talked to him about a month ago and he hadn't made much
headway.

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

Marc G. Fournier wrote:

I meant related to PITR? :)

On Thu, 30 Oct 2003, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Fri, 31 Oct 2003, Tatsuo Ishii wrote:

Nope, not for those items. There is still some thought of a very short
release cycle (a few months) for 7.5, and we could possibly address the
vacuum issue in that timeframe, if the recent ideas about it prove out.
But there is no consensus on how to fix the integer-index issues, and
I'm not willing to hold 7.4 (or even 7.5) hostage to finding one.

The idea of very short release cycle for 7.5 is interesting. What is
the core's decision for point-in-time-recovery? Maybe the decision is
7.5 does not include point-in-time-recovery?

Does anyone have anything ready to put into CVS as soon as we start v7.5,
or shortly afterwards?

Well, I have patches2:

http:/momjian.postgresql.org/cgi-bin/pgpatches2

There are a few things ready for application in there, plus other items
to start work on.

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

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