Dave Page wrote:
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] 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
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
