Skip site navigation (1) Skip section navigation (2)

Remote administration functionality

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Magnus Hagander <mha(at)sollentuna(dot)net>,PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Remote administration functionality
Date: 2005-07-31 03:39:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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                        |
  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

In response to


pgsql-hackers by date

Next:From: Steve AtkinsDate: 2005-07-31 04:35:16
Subject: Re: Remote administration functionality
Previous:From: Larry RosenmanDate: 2005-07-31 02:53:01
Subject: Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive

pgsql-patches by date

Next:From: Steve AtkinsDate: 2005-07-31 04:35:16
Subject: Re: Remote administration functionality
Previous:From: Bruce MomjianDate: 2005-07-31 02:36:05
Subject: Re: PL/PGSQL: Dynamic Record Introspection

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group