Re: Server instrumentation patch

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> Sent: 21 June 2005 18:06
> To: Dave Page
> Cc: PostgreSQL-development; Andreas Pflug
> Subject: Server instrumentation patch
>
>
> 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.

The reason it happen that way was because we already had the code as a
contrib-style module for pgAdmin. It was posted because we recognised
that it was becoming a PITA for pgAdmin users to compile a new
server-side component and the functions seemed like they would be useful
to other tools similar to pgAdmin.

Yes, this is not the normal way to proprose new features, but I'm sure
you appreciate that as picture speaks a thousand words, posting the
*existing* code with minor changes to properly integrate it shows
exactly what is being proposed, both in functional and impelmentation
detail.

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

OK, first it was the 10th of June which is a little more than two weeks,
however, Andreas clearly did reference previous discussions on the
subject - see his message
http://archives.postgresql.org/pgsql-patches/2005-06/msg00226.php in
which he points out that 2 functions are from the logger suprocess patch
from 07/2004, that the file related stuff is based on discussions
starting at
http://archives.postgresql.org/pgsql-patches/2004-07/msg00287.php,
including comments from yourself!!

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

No. I cannot argue with that, and for that reason I suggested that
Andreas repost the patch without that function so it can be properly
discussed and implemented in a safe way in the future. I'm sure you have
see the reposted patch.

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

Well as far as I can see, Andreas did respond to all queries about it,
and then posted his updated patch after it became apparent noone else
was going to discuss the issue further -
http://archives.postgresql.org/pgsql-patches/2005-06/msg00309.php. From
what I can see, no-one has argued or disagreed with his opinion given a
few days to do so, therefore there was nothing further to discuss.

Unfortunately sometimes people don't respond - either because they don't
care, or because they agree. Either way, *we* cannot force a discussion,
and in this sort of development model we have no choice than to assume
that if discussion of a issue stops and there are no outstanding
queries, concerns or objections, it's because it's everyone is happy for
the result of those discussions to be accepted into the project.

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

With the exception of the now removed pg_terminate_backend, I am unaware
of any issues that are outstanding. If the committers have issues they
*must* raise them for *any* submitted patch otherwise developers will
lose faith in the process when their hard work gets ignored.

Now, to try to get this ball rolling again - do the committers or anyone
else have any outstanding issues with the instrumentation or dbsize
patches that haven't been answered in public discussion and addressed in
the patches already?

Regards, Dave.