-----Original Message-----
From: Bruce Momjian [mailtogman@candle.pha.pa.us]
Sent: Sun 7/31/2005 2:58 PM
To: Dave Page
Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality


> I was thinking of a global table that can be modified with
> INSERT/UPDATE/DELETE and is then dumped to a flat file, like we do with
> pg_shadow.

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.

Unless you're advocating only allowing pg_hba modifications via the server, in which case it must be started in default configuration before any mods can be made. That doesn't seem like a good idea to me :-(

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

Dave Page wrote:
>
>
>
> -----Original Message----- From: Bruce Momjian
> [mailtogman@candle.pha.pa.us] Sent: Sun 7/31/2005 2:58 PM To: Dave
> Page Cc: Tom Lane; Magnus Hagander; PostgreSQL-development Subject:
> Re: [HACKERS] Remote administration functionality
>
>
> > I was thinking of a global table that can be modified with
> > INSERT/UPDATE/DELETE and is then dumped to a flat file, like we do with
> > pg_shadow.
>
> 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.
>
> Unless you're advocating only allowing pg_hba modifications via the
> server, in which case it must be started in default configuration before
> any mods can be made. That doesn't seem like a good idea to me :-(

I am thinking we will need load_pg_hba() and write_pg_hba() that will
load and write the table to pg_hba.conf.

--
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, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bruce Momjian wrote:
> Dave Page wrote:

>>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.
>>
>>Unless you're advocating only allowing pg_hba modifications via the
>>server, in which case it must be started in default configuration before
>>any mods can be made. That doesn't seem like a good idea to me :-(
>
>
> I am thinking we will need load_pg_hba() and write_pg_hba() that will
> load and write the table to pg_hba.conf.

Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
GUCs with pg_settings is the GUC like a table, but with comments that
exceed config_generic.long_desc.

Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Dave Page wrote:
>
> >>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.
> >>
> >>Unless you're advocating only allowing pg_hba modifications via the
> >>server, in which case it must be started in default configuration before
> >>any mods can be made. That doesn't seem like a good idea to me :-(
> >
> >
> > I am thinking we will need load_pg_hba() and write_pg_hba() that will
> > load and write the table to pg_hba.conf.
>
> Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
> GUCs with pg_settings is the GUC like a table, but with comments that
> exceed config_generic.long_desc.

Well, pg_hba.conf is ordered, which is different, and it more of a
columnar values that postgresql.conf.

--
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, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Bruce Momjian wrote:

>>
>>Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
>>GUCs with pg_settings is the GUC like a table, but with comments that
>>exceed config_generic.long_desc.
>
>
> Well, pg_hba.conf is ordered,

From a text editor user's view, postgresql.conf is ordered too. I'd be
annoyed if some function would screw it up; same with comments which are
deliberately placed where they are.

> which is different, and it more of a
> columnar values that postgresql.conf.

Hm, pg_settings gives me the same picture.

Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >>
> >>Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
> >>GUCs with pg_settings is the GUC like a table, but with comments that
> >>exceed config_generic.long_desc.
> >
> >
> > Well, pg_hba.conf is ordered,
>
> From a text editor user's view, postgresql.conf is ordered too. I'd be
> annoyed if some function would screw it up; same with comments which are
> deliberately placed where they are.

True, but there is no purpose to modify the ordering of postgresql.conf,
while with pg_hba.conf, there is a need to do that. Also,
postgresql.conf has a fixed set of lines, while pg_hba.conf doesn't.

> > which is different, and it more of a
> > columnar values that postgresql.conf.
>
> Hm, pg_settings gives me the same picture.

Yes, we could use that for updates, rather than SET GLOBAL. Good point.
However, it seems SET GLOBAL is a cleaner API, while we can't use such a
nice API for pg_hba.conf.

--
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, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC7jRmrzgMPqB3kigRAkPJAKCW/WwZxyKNhmA1fPUxzS88OwKQ2ACfZsm+
uJw7H1fHw7txBeldCPJI3MY=
=uaV/
-----END PGP SIGNATURE-----

Stephen Frost <sfrost@snowman.net> writes:
> 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 .

(1) pg_hba.conf is fundamentally order-sensitive; SQL tables are
fundamentally not. I think it would be a bad idea to try to make
pg_hba.conf be an image of a SQL table.

(2) You have to be able to edit pg_hba.conf manually before you start
the server for the first time.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > 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 .
>
> (1) pg_hba.conf is fundamentally order-sensitive; SQL tables are
> fundamentally not. I think it would be a bad idea to try to make
> pg_hba.conf be an image of a SQL table.

You could, of course, have an 'order by' and a column which specifies
the ordering to be applied. I'm not entirely convinced pg_hba is best
as an ordered setup anyway, and this would perhaps be an opportunity to
move it from first-match to best-match.

> (2) You have to be able to edit pg_hba.conf manually before you start
> the server for the first time.

We could have a default setup and options to initdb to create it
correctly if you need something different initially. I'm not convinced
you couldn't have a decent default anyway though.

Thanks,

Stephen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC7jadrzgMPqB3kigRApP9AJ9wqhGKg3phbLCMzxngAm 4ro73tSwCdEVk4
vyxoZ5O0aBVSi4c1aNKktoI=
=TCCy
-----END PGP SIGNATURE-----