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.conf
o edit pg_hba.conf
o reload the config files
o restart the server (for config variables requiring restart)
o view log files
o recycle log files
o 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(at)postgresql(dot)org so that
> your message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073