Re: Server instrumentation patch

Bruce Momjian wrote:

>Dave Page wrote:
>  
>
>>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.
>>    
>>
>
>Sure.
>
>  
>
>>>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.
>>    
>>
>
>OK.
>
>  
>
>>>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. 
>>    
>>
>
>Well, I see Marc replying that dbsize should be moved completely from
>contrib:
>
>    http://archives.postgresql.org/pgsql-patches/2005-06/msg00409.php
>
>The current version of the patch only moves those functions he wants. 
>Marc says he wants them all moved, and I agree.
>
>  
>
>>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.
>>    
>>
>
>Well, from the May, 2005 discussion URL you posted, I see a clear reply
>to the idea of adding the I/O functions to the backend:
>
>    http://archives.postgresql.org/pgsql-hackers/2005-05/msg00874.php
>
>Now, you can agree or disagree that there are issues with the I/O
>functions, but the concern was raised in May, and not addressed at all,
>either via email or the patch.
>
>  
>
>>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?
>>    
>>
>
>OK, agreed, how can we move forward?  The patch has three parts:
>
>    o  file I/O
>    o  move dbsize from contrib
>    o  backend terminate
>
>For the first, we need to re-discuss this on hackers.  I found this as
>the conclusion from July of 2004 as it relates to the I/O functions:
>
>    http://archives.postgresql.org/pgsql-patches/2004-07/msg00561.php
>
>However, the TODO items still exist so we can discuss it and hopefully
>resolve it by feature freeze.
>
>For the second, please supply a patch that moves _all_ of dbsize into
>the main server.  I think we have agreement on that.
>  
>

I don't think so. As I mentioned, those views are broken. Do you want 
them to be in core anyway?

Regards,
Andreas