Remote administration functionality

Let me try to outline where I think our goals are for remote
administration.  I will not comment on Dave's analysis of the patch
review process, but I think he has some valid points that this patch was
not treated properly.

Basically, I think everyone wants remote administration.  Remote
administration requires several things:
o  edit postgresql.confo  edit pg_hba.confo  reload the config fileso  restart the server (for config variables
requiringrestart)o  view log fileso  recycle log fileso  rename/remove log files
 

All these items are on the TODO list already.

The idea of the patch was to give applications the full unix I/O
capabilities, allowing them to program these functions into
administration applications.  I think the group generally would like a
higher-level API that allows something like:
SET GLOBAL log_statement = 'mod';

that would modify postgresql.conf and signal all backends to-read the
file, or a way to control pg_hba.conf using SQL queries.  

While the Unix API works, it isn't really what we finally want for
remote administration.  I thought this was discussed back in the 8.0
beta period, and was surprised to see the file I/O patch resurface, but
because no one objected to it, I moved forward to getting it into the
queue and applied.  Later, others did object, some to the too-general
API, others based on security concerns.  

I probably should have stated more clearly that the high-level API was
the proper approach, rather than moving forward with a patch I knew
untimately would lead to concerns.  However, I try to refrain from
pre-judging a patch lest I become too unbiased toward patch submissions.
I try to be the advocate for patches, rather than cast judgement. (What
surprised me is that the concerns didn't surfaced so late.)  

So, where does this leave us for 8.1?  I don't think we have time to
implement many of the bulleted items listed above, and I don't think the
file API patch would pass a vote, but I will support a vote if people
want that.

I think it might be possible to do a few of the bulleted items while we
clean out the patches queue.  In fact, I think the reload the config
file functionality was already in the file I/O patch, so we can easily
apply that.  (It is a TODO item.)

Given the confusion about the patch, I think we can give folks some time
to work on any additional remote administration bulleted items while we
clean out the patches queue.

Does that sound like a plan?

[ FYI, I think some of the bulleted items can be done now via COPY.]

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

Dave Page wrote:
> 
> 
> 
> > None of these functions are getting into 8.1 anyway; we should be
> > designing the long-term solution not making up short-lived hacks.
> 
> So, going back to pre 8.0, we fixed them so they don't work outside of
> the data directory as requested, yet they were not included for unknown
> reasons.
> 
> We revisited some weeks before prior to feature freeze, and I researched
> all issues raised and ask for clarification on what you weren't happy
> with as all I'd found in the archives was a sentence along the lines
> of "I really don't see any value in these". I found no outstanding
> issues in the archives, nor did I receive any in response to my
> questions.
> 
> Having received no further objections, the patch was added to the queue.
> As soon as Bruce starts to look at it, presumably to apply it, you
> decide it's an unacceptable security problem, and say you'd be
> perfectly happy if there was a GUC to disable the potentially dangerous
> functions. This info would have been nice before feature freeze, but,
> OK, I appreciate you're busy.
> 
> Magnus updates the patch because he's yet another one of us that thinks
> this is useful functionality and adds the GUC you said would make you
> happy with these functions.
> 
> You then state, with no discussion at all, that they're not going into
> 8.1 anyway, despite us doing everything you have asked.
> 
> I have two questions if I may:
> 
> 1) Is there any point us working on any kind of enhanced API for remote
> admin in the future, or will the same treatment be given to that?
> 
> 2) Do you now have sole say over what does and doesn't go into the
> project?
> 
> I don't mean to be disrespectful - your hard work and skills are hugely
> appreciated by the whole community, but I know for a fact that a number
> of them, who between them have contributed thousands of hours and lines
> of code to the project (and I'm talking about the core project, never
> mind pgAdmin et al) cannot understand your apparent insistence on us
> not providing remote admin capabilities. I think we simply need
> clarification on how the project works these days.
> 
> Regards, Dave
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>   subscribe-nomail command to majordomo@postgresql.org so that
>   your message can get through to the mailing list cleanly
> 

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