Schedule for 8.1 feature freeze

Started by Bruce Momjianalmost 21 years ago43 messageshackers
Jump to latest
#1Bruce Momjian
bruce@momjian.us

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 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
#2Dave Page
dpage@pgadmin.org
In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 21 June 2005 05:04
To: PostgreSQL-development
Subject: [HACKERS] Schedule for 8.1 feature freeze

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a
feature freeze
on July 1.

What about Andreas' instrumentation stuff? This has been going on since
before 8.0 and it would good to get it in 8.1 given the amount of extra
functionality it allows us to offer users that prefer a GUI interface.

I realise there probably won't be time to fix pg_terminate_backend, or
convince people that it offers the admin the lesser of two evils (my
limited understanding being that there is a chance of it not clearing
some locks, vs, having to shut down the whole server to kill a single
connection) - can we at least get the other functions applied?

Thanks, Dave.

#3Magnus Hagander
magnus@hagander.net
In reply to: Dave Page (#2)
Re: Schedule for 8.1 feature freeze

We have addressed all the open issues for 8.1 except for
auto-vacuum, which Alvaro is working on, so I think we are
ready for a feature freeze on July 1.

I don't beleive we have :-(

The server instrumentation patch is not yet addressed. Last I checked
there was the objections to pg_terminate_backend (which are certainly
valid,though I and many other still claim this is in daily use at *a
lot* of installations), and nothing substantial to the rest of the
patch. yet it hasn't even made it to the queue (the patch would still be
very useful with just the parts except pg_terminate_backend). I beleive
Andreas is working on separating out the pg_terminate_backend part to a
separate patch to make it easier for whomever would apply it.

There is also the ICU patch. this is *very* much needed for win32, and
from how I read it it's also needed for other platforms. Last I heard
Palle planned to have it fixed up before feature freeze (I'm not sure
exactly what more needed to be fixed). If not then we have to do
something else about unicode on win32 (perhaps under the flag of
"bugfix", but I'm sure it will be more invasive than most would like).
But I realy think a cross-platform thing like ICU is much better.

And there's a pending patch that redoes signal handling on win32. I
haven't had the time to check it through myself, as I've been
unexpectedly-out-of-town several times lately, but it was posted some
time ago and shoudl probalby be at least considered. (I'm not 100% sure
it's a worthwhile simplification myself, but I'll have to look into it
muc more careful before I can form an actual opinion on it)

Finally a heads-up: I'm looking at an updated patch to remove the
Kerberos V4 support. I posted to both hackers and general a month ago
asking for people who use it for exactly zero responses. It's not quite
done yet, but I plan to have it done before July 1st. But it's definitly
not something to hold up a freeze date for if I'm not.

Is there an "Open Issues" list yet, as you usually prepare for releases?
If so, can you please put these items up on it?

//Magnus

#4Oleg Bartunov
oleg@sai.msu.su
In reply to: Dave Page (#2)
Re: Schedule for 8.1 feature freeze

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 21 June 2005 05:04
To: PostgreSQL-development
Subject: [HACKERS] Schedule for 8.1 feature freeze

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a
feature freeze
on July 1.

Bruce, we're working on GiST concurrency which is based on GiST recovery
code already submitted. Hopefully, we'll submit patch before July 1.
There is also one problem we already discussed - we have no gist opclasses
in core we could use for regression tests ! Probably, it's a time we need
to add some opclasses from intarray or rtree_gist to core ?

btw, there was a noise about funding of our work, but I've contacted only
with PostGis guys about real contribution. I'm just wondered if any
commercial clones do really understand the importance of our work. Should
I write some explanation what're recovery and concurrency for GiST ?

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

#5Stephen Frost
sfrost@snowman.net
In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

* Bruce Momjian (pgman@candle.pha.pa.us) wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.

Bruce,

I'd really like to see role support added into 8.1. I've sent Alvaro
and Tom versions of the patch in the past and I was planning on
submitting it to -patches soon. There's a few remaining issue but I
don't think they'll take very long to clean up; I've just been
unfortunately pretty busy lately. I'm hopeful that I'll be able to
spend some time on it this week and next week to hopefully address at
least the remaining issues on my list.

Lookups need to do multi-level role resolution (for owner and other
ACL areas)
(Not very hard, and mostly isolated to the acl code)
Need to implement per-backend role-member cacheing
(Not very hard, basically same kind of way pg_namespace does
schema_path)
Support 'grant <role> to <role>'
(Shouldn't be too difficult, mainly just parser work)
Support 'with admin option'
(Somewhat difficult, but not necessary for the same functionality we
have today)
Support 'granted by'
(Not very hard, just parser work really)
Fix other parsers (ecpg, etc) based on updates to backend/parser.
(Worked on this some already, should be done real soon now)
Distinguish 'create role' permissions from 'superuser'?
(Not sure if this makes sense)

Modify \du, \dg to use new tables
(They work already using the backwards-compat views, just would be
nice to update them to the new schema).
? Add \dr, \dm
(Should be easy and would be nice I think, though perhaps not
required)

Add documentation for CREATE ROLE/etc
Document new system catalogs (pg_authid, pg_auth_members)
(Documentation updates)

There are views for pg_shadow/pg_group and things seem to be happy
with them. CREATE USER/CREATE GROUP work more-or-less as expected.
An interesting side-effect is that if you do 'create group' and then
look in the 'group' table you don't see the group till you actually
put users in it. Not entirely sure if anything actually depends on
that (You can, after all, still grant rights to the role which was
created by CREATE GROUP, and do ALTER GROUP on it, etc).

Thanks,

Stephen

#6Rod Taylor
rbt@rbt.ca
In reply to: Dave Page (#2)
Re: Schedule for 8.1 feature freeze

I realise there probably won't be time to fix pg_terminate_backend, or
convince people that it offers the admin the lesser of two evils (my
limited understanding being that there is a chance of it not clearing
some locks, vs, having to shut down the whole server to kill a single
connection) - can we at least get the other functions applied?

Not clearing those locks frequently results in a "Lock Table corruption"
message and panic at some unknown point in the future, and is probably
not something we want to encourage.

It looks really bad when it happens hours or days after the connection
was killed because the user isn't going to associate those two actions.

This is a feature I'm really looking forward too, but it's not ready for
general consumption yet.

--

#7Tom Lane
tgl@sss.pgh.pa.us
In reply to: Stephen Frost (#5)
Re: Schedule for 8.1 feature freeze

Stephen Frost <sfrost@snowman.net> writes:

I'd really like to see role support added into 8.1. I've sent Alvaro
and Tom versions of the patch in the past and I was planning on
submitting it to -patches soon. There's a few remaining issue but I
don't think they'll take very long to clean up; I've just been
unfortunately pretty busy lately. I'm hopeful that I'll be able to
spend some time on it this week and next week to hopefully address at
least the remaining issues on my list.

Stephen, it is not going to be acceptable to sit on that patch until
June 30 --- there are other things depending on it. If you don't have
time for it now, send in what you have so that someone else can pick up
the ball.

regards, tom lane

#8Stephen Frost
sfrost@snowman.net
In reply to: Tom Lane (#7)
Re: Schedule for 8.1 feature freeze

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Stephen Frost <sfrost@snowman.net> writes:

I'd really like to see role support added into 8.1. I've sent Alvaro
and Tom versions of the patch in the past and I was planning on
submitting it to -patches soon. There's a few remaining issue but I
don't think they'll take very long to clean up; I've just been
unfortunately pretty busy lately. I'm hopeful that I'll be able to
spend some time on it this week and next week to hopefully address at
least the remaining issues on my list.

Stephen, it is not going to be acceptable to sit on that patch until
June 30 --- there are other things depending on it. If you don't have
time for it now, send in what you have so that someone else can pick up
the ball.

Sorry, I thought that's what I had been doing when sending to
you/Alvaro/-hackers earlier.. I'll send in what I've got and I guess
see what happens. I'm planning on still working on it when I have time
available so if someone else picks it up to work on it, please let me
know so we can coordinate.

Thanks,

Stephen

#9Tom Lane
tgl@sss.pgh.pa.us
In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

Bruce Momjian <pgman@candle.pha.pa.us> writes:

We have addressed all the open issues for 8.1 except for auto-vacuum,

Aside from the other stuff people mentioned, I have these things on
my to-look-at list:

* Fix pg_dump to be able to dump large objects in text dumps

* Fix inherited constraints (per discussion around 5/20)

* Fix reporting of table/column numbers for cursors (per DeSoi, 4/9)

* statement_timeout does not behave very reasonably for V3 messages

And I'd really like to see pg_role and shared dependencies get in...

regards, tom lane

#10Andrew Dunstan
andrew@dunslane.net
In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

Bruce Momjian wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.

FYI - plperl status.

I am trying to get the following 2 items done by feature freeze:
. convert returned perl array to pg array (see patch recently sent for
discussion)
. validator function

The remaining memory issue we have is where plperl does a huge select
via SPI. Abhijit Menon-Sen was working on this but is stumped on how to
proceed (see his previous message). We have a patch from CommandPrompt
which apparently improves the situation, although it doesn't solve the
basic problem. If we don't make progress with Abhijit's work, I will
look at working that up by July 1.

There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.

cheers

andrew

In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

I'll do my best to submit bitmap index AM patch next week for your review.

--

Victor Y. Yegorov

#12Bruce Momjian
bruce@momjian.us
In reply to: Dave Page (#2)
Server instrumentation patch

Dave Page wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Bruce Momjian
Sent: 21 June 2005 05:04
To: PostgreSQL-development
Subject: [HACKERS] Schedule for 8.1 feature freeze

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a
feature freeze
on July 1.

What about Andreas' instrumentation stuff? This has been going on since
before 8.0 and it would good to get it in 8.1 given the amount of extra
functionality it allows us to offer users that prefer a GUI interface.

I realise there probably won't be time to fix pg_terminate_backend, or
convince people that it offers the admin the lesser of two evils (my
limited understanding being that there is a chance of it not clearing
some locks, vs, having to shut down the whole server to kill a single
connection) - can we at least get the other functions applied?

[ CC to Andreas.]

OK, let me address this, but you might not like what I have to say. ;-)

Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch. Saying
pgadmin needs it just isn't enough to get a patch in. There are the
issues of security and maintainability that have to be addressed, and
in the limited time we had to do this in 8.0, it was clear the patch
should not be applied.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze, with no discussion, the patch appears, and makes no reference to
concerns raised during the 8.0 discussion. pg_terminate_backend is even
in the patch, and there is no mention or attempt to address concerns we
had in 8.0.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?

This needs discussion, not a patch. And because there are so many
assumptions made in the patch, the patch committers look unreasonable
asking for X changes to his patch, when in fact he made X assumptions in
the patch and never asked anyone before developing the patch about those
assumptions.

Basically, I think this is a great example of how _not_ to do things in
the community:

o don't post your proposal for discussion
o don't mention controversial issues in your patch
o don't fully address code migrations in your patch

It seems like the goal is to throw in the patch on the hopes that no one
will remember or realize the problems before it gets into CVS.

What has to happen now is that we need to restart the server
instrumentation discussion with a proposal of what needs to be added to
the server, and why, and then we can deal with any concerns raised. The
same is true with the dbsize patch.

Bad news, yea, but I think it is the only way to move forward.

-- 
  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
#13Bruce Momjian
bruce@momjian.us
In reply to: Andrew Dunstan (#10)
Re: Schedule for 8.1 feature freeze

Andrew Dunstan wrote:

There is also the tiny patch to trap lexical warnings I submitted not
long ago still outstanding.

OK, I missed that one. I see it at:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00280.php

However, I don't see the new regession files attached to that URL.
Would you repost please?

-- 
  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
#14Bruce Momjian
bruce@momjian.us
In reply to: Magnus Hagander (#3)
Re: Schedule for 8.1 feature freeze

Magnus Hagander wrote:

Is there an "Open Issues" list yet, as you usually prepare for releases?
If so, can you please put these items up on it?

Yes, it is at:

This item has been added to the 7.4 open items list:

http://candle.pha.pa.us/cgi-bin/pgopenitems

It did contain only pgautovacuum, but has been updated with the new
items.

-- 
  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
#15Greg Sabino Mullane
greg@turnstep.com
In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature freeze
on July 1.

FWIW, I'm still working on column-level triggers, but the July 1st deadline
should not be a problem.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200506211841
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFCuJe+vJuQZxSWSsgRAkSnAKDhwsRXoupe1DhHGgCYrquimK9CJQCgz1K5
/nHRvPxNs+41vxs7G9ngvW4=
=C+M3
-----END PGP SIGNATURE-----

#16Michael Glaesemann
grzm@seespotcode.net
In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature
freeze
on July 1.

I'm hoping to add documentation and regression tests for interval-

day over the next couple of days and have that ready for 8.1 as well.

Michael Glaesemann
grzm myrealbox com

#17Michael Glaesemann
grzm@seespotcode.net
In reply to: Bruce Momjian (#1)
Re: Schedule for 8.1 feature freeze

On Jun 21, 2005, at 1:03 PM, Bruce Momjian wrote:

We have addressed all the open issues for 8.1 except for auto-vacuum,
which Alvaro is working on, so I think we are ready for a feature
freeze
on July 1.

I'm hoping to add documentation and regression tests for interval-

day over the next couple of days and have that ready for 8.1 as well.

Michael Glaesemann
grzm myrealbox com

#18Josh Berkus
josh@agliodbs.com
In reply to: Michael Glaesemann (#17)
Re: Schedule for 8.1 feature freeze

People:

Oh, and in implementing the COPY stuff we realized that there weren't any
regression tests for encodings. If we can figure out how to do them,
we'll add those. Are new regression tests permitted during beta?

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

#19Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Bruce Momjian (#12)
Re: Server instrumentation patch

Bruce Momjian wrote:

Dave Page wrote:

Basically, Andreas' approach for 8.0 was to develop a patch (without
posting a proposal or interface), and then argue why pgadmin needs it,
but without addressing the real concerns about the patch.

Extending the logging was to get a means of reading the log file without
console access, with *any* client.
The proposal to develop the generic file functions came from a Mr Bruce
Momjian.

Saying
pgadmin needs it just isn't enough to get a patch in.

Never said that. It's needed by dbadmins without console access.

There are the
issues of security and maintainability that have to be addressed,

All issues were discussed and solved.

and
in the limited time we had to do this in 8.0, it was clear the patch
should not be applied.

Now, in 8.1, the same thing has happened. Two weeks before feature
freeze,

I posted it on June 1st.

with no discussion, the patch appears, and makes no reference to

concerns raised during the 8.0 discussion.

RTFM. The lengthy original discussion which addressed _all_ issues is
referenced.

pg_terminate_backend is even

in the patch, and there is no mention or attempt to address concerns we
had in 8.0.

I never intended to address the issues, I wanted to address the every
day problem to kill a backend without killing the server. Drop it, for
god's sake.

The move of dbsize into the backend is similar. He moves the parts of
dbsize the pgadmin needs into the backend, but makes no mention or
change to /contrib/dbsize to adjust it to the movement of the code. He
has since posted and updated version that fixes this, I think, but
again, we have to discuss how this is to be done --- do we move all the
dbsize functions into the backend, some, or none? Do the other dbsize
functions stay in /contrib or get deleted?
This needs discussion, not a patch. And because there are so many
assumptions made in the patch, the patch committers look unreasonable
asking for X changes to his patch, when in fact he made X assumptions in
the patch and never asked anyone before developing the patch about those
assumptions.

This was discussed lengthy starting May 11th, except for the broken
dbsize functions. My post is the result from that.

Regards,
Andreas

#20The Hermit Hacker
scrappy@hub.org
In reply to: Josh Berkus (#18)
Re: Schedule for 8.1 feature freeze

On Tue, 21 Jun 2005, Josh Berkus wrote:

People:

Oh, and in implementing the COPY stuff we realized that there weren't any
regression tests for encodings. If we can figure out how to do them,
we'll add those. Are new regression tests permitted during beta?

Yes, most definitely ... especially if they happen to pick up a bug at the
same time :)

Anything that improves *testing* or *documentation* should be no-brainers
for addition during the release process, since they both improve the end
product without affecting the backend code itself ...

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

#21Tom Lane
tgl@sss.pgh.pa.us
In reply to: Josh Berkus (#18)
#22Bruce Momjian
bruce@momjian.us
In reply to: Andreas Pflug (#19)
#23The Hermit Hacker
scrappy@hub.org
In reply to: Bruce Momjian (#22)
#24Neil Conway
neilc@samurai.com
In reply to: Bruce Momjian (#1)
#25Fabien COELHO
coelho@cri.ensmp.fr
In reply to: Stephen Frost (#5)
#26Dave Page
dpage@pgadmin.org
In reply to: The Hermit Hacker (#23)
#27Dave Page
dpage@pgadmin.org
In reply to: Dave Page (#26)
#28Bruce Momjian
bruce@momjian.us
In reply to: Dave Page (#26)
#29Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Bruce Momjian (#28)
#30Dave Page
dpage@pgadmin.org
In reply to: Andreas Pflug (#29)
#31Michael Paesold
mpaesold@gmx.at
In reply to: Bruce Momjian (#28)
#32Andreas Pflug
pgadmin@pse-consulting.de
In reply to: Michael Paesold (#31)
#33Dave Page
dpage@pgadmin.org
In reply to: Andreas Pflug (#32)
#34Jim Nasby
Jim.Nasby@BlueTreble.com
In reply to: Dave Page (#33)
#35Michael Paesold
mpaesold@gmx.at
In reply to: Bruce Momjian (#28)
#36Michael Paesold
mpaesold@gmx.at
In reply to: Dave Page (#33)
#37Bruce Momjian
bruce@momjian.us
In reply to: Dave Page (#33)
#38Bruce Momjian
bruce@momjian.us
In reply to: Dave Page (#30)
#39Dave Page
dpage@pgadmin.org
In reply to: Bruce Momjian (#38)
#40Bruce Momjian
bruce@momjian.us
In reply to: Dave Page (#39)
#41Dave Page
dpage@pgadmin.org
In reply to: Bruce Momjian (#40)
#42Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#13)
#43Bruce Momjian
bruce@momjian.us
In reply to: Bruce Momjian (#42)