Re: Remote administration functionality - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Remote administration functionality
Date
Msg-id 20050801144038.GA6026@ns.snowman.net
Whole thread Raw
In response to Re: Remote administration functionality  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Remote administration functionality  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > >>The problem is, pg_hba.conf might be editted via the OS unlike the text
> > >>version of pg_shadow which is only editted via the server, which would
> > >>make appropriate locking nigh-on impossible afaics.

Alright, sorry to just jump in here in the middle, but I don't see why
pg_hba.conf couldn't be made to work just like pg_shadow (or rather,
pg_authid or whatever it is now :).  It's a file on the disk, created
initially by initdb, used for initial backend-startup, but 'owned' by
the database.  It's also a catalog-table, and the file is written out
every time the catalog-table is modified.

We could implement some functions, or adjust things like ALTER, to make
working with the catalog-table a little nicer/easier, etc.  For
pg_hba.conf, that seems like the most sensible way (to me, anyway) to
make it remotely-administratable.

Generally I'd think the same of the other config files, though I do
appriciate the concern about how to safely restart remotely and
associated with that 'testing' the changes somehow before reverting
back.  Although, it seems like that could be done with files too I'd
think.  Upon a remote restart if the backend fails to start with file X,
it reverts back to the file it was originally started with.

Just my 2c.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Sam Mason
Date:
Subject: Re: Remote administration functionality
Next
From: Douglas McNaught
Date:
Subject: Re: Remote administration functionality