-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 01:35
To: Dave Page
Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
I am thinking we will need load_pg_hba() and
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
Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 01:35
To: Dave Page
Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
I am thinking we will need
I am thinking we will need load_pg_hba() and write_pg_hba() that
will load and write the table to pg_hba.conf.
Yeah, that bit is straghtforward enough, but what about the
situation
where dba #1 updates the pg_hba table, at the same time as
dba #2 is
editting pg_hba.conf in
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
On Mon, Aug 01, 2005 at 12:28:55AM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Luke Lonergan wrote:
Has there been any agreement or a concept for remote reboot?
Reload of config file and rotate log files were part of the original
patch that I will try to apply.
Magnus Hagander wrote:
I am thinking we will need load_pg_hba() and write_pg_hba() that
will load and write the table to pg_hba.conf.
Yeah, that bit is straghtforward enough, but what about the
situation
where dba #1 updates the pg_hba table, at the same time as
dba #2 is
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
-Original Message-
From: Magnus Hagander [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:18
To: Bruce Momjian
Cc: Dave Page; Tom Lane; PostgreSQL-development
Subject: RE: [HACKERS] Remote administration functionality
It allows remote administration, and by using columns for
The difference is that if the other admin edited it in vi
*last week*
it will still break with your way, unless every admin
always rembers
to do
load_pg_hba() before doing *anything at all*.
Yes, good point. In thinking about this, I think we are
better having the load()
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
Magnus Hagander wrote:
The difference is that if the other admin edited it in vi *last week* it
will still break with your way, unless every admin always rembers to do
load_pg_hba() before doing *anything at all*.
What if you send patches over the wire rather than the whole or
subsets of the
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
Stephen Frost [EMAIL PROTECTED] 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
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:41
To: Bruce Momjian
Cc: Andreas Pflug; Dave Page; Tom Lane; Magnus Hagander;
PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
The problem is,
Dave Page dpage@vale-housing.co.uk writes:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
I am thinking we will need load_pg_hba() and write_pg_hba() that will
load and write the table to pg_hba.conf.
Yeah, that bit is straghtforward enough, but what about
-Original Message-
From: Douglas McNaught [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:16
To: Dave Page
Cc: Bruce Momjian; Tom Lane; Magnus Hagander; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
Dave Page dpage@vale-housing.co.uk
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] 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
-Original Message-
From: Stephen Frost [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:51
To: Dave Page
Cc: Bruce Momjian; Andreas Pflug; Tom Lane; Magnus Hagander;
PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
This isn't actually an
* Dave Page (dpage@vale-housing.co.uk) wrote:
This isn't actually an argument against my proposal. The
admin doesn't
edit pg_shadow using vi because it's understood to be 'owned' by the
database. The same would be true of 'pg_hba' in my solution.
Only if it were moved to a different
* Dave Page (dpage@vale-housing.co.uk) wrote:
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 :).
Because the admin doesn't edit pg_shadow using vi or some other
Magnus Hagander wrote:
The difference is that if the other admin edited it in vi
*last week*
it will still break with your way, unless every admin
always rembers
to do
load_pg_hba() before doing *anything at all*.
Yes, good point. In thinking about this, I think we are
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 01 August 2005 15:36
To: Magnus Hagander
Cc: Dave Page; Tom Lane; PostgreSQL-development
Subject: Re: [HACKERS] Remote administration functionality
Uh, not sure why it would be harder. What system would be
I fail to see how this is better than just editing the
file. Because
it basically *is* a file editing function limited to
pg_hba.conf.
Perhaps what we need is a file reader/writer that is
hardcoded to the
pg_hba.conf file?
It allows remote administration, and by
Jonah,
Thanks for your comments.
Jonah H. Harris writes:
I have a lot of shell scripts that run as cron jobs and have considered
this option. However, if you look at it carefully, SQL is totally
different from say perl, php, bash, etc. for scripts which execute from
the shell. Tom
Hello,
What might this be?
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG -
On Mon, Aug 01, 2005 at 11:58:34AM -0700, Joshua D. Drake wrote:
What might this be?
Whether to warn on '\' in non-E'' strings.
AFAIK Bruce wants to turn this to 'on' in 8.2.
--
marko
---(end of broadcast)---
TIP 9: In versions below 8.0, the
All the items you mentioned look like 8.2 issues to me. But here are
some thoughts.
Alvaro Herrera wrote:
* Enable autovacuum by default.
Get some field experience with it first, so the worst bugs are covered.
(Has anybody tested it?)
I have done some testing and it seems to be
On 2005-08-01, Matthew T. O'Connor matthew@zeut.net wrote:
* Stop a running VACUUM if the system load is too high.
What if vacuum used a vacuum delay that was equal to the vacuum delay
GUC settings * the system load. Or something more sophisticated but
this would have the effect of having
Andrew - Supernews wrote:
On 2005-08-01, Matthew T. O'Connor matthew@zeut.net wrote:
* Stop a running VACUUM if the system load is too high.
What if vacuum used a vacuum delay that was equal to the vacuum delay
GUC settings * the system load. Or something more sophisticated but
On Mon, Aug 01, 2005 at 10:22:14PM -0400, Matthew T. O'Connor wrote:
[..snipped..]
Right which is why we would need to enforce some max value so that
vacuuming will never be totally squeezed out.
greetings,
I'm a linux guy, so please forgive my ignorance, but is it even possible to
On Mon, Aug 01, 2005 at 10:35:00PM -0400, Jeff MacDonald wrote:
On Mon, Aug 01, 2005 at 10:22:14PM -0400, Matthew T. O'Connor wrote:
[..snipped..]
Right which is why we would need to enforce some max value so that
vacuuming will never be totally squeezed out.
I'm a linux guy, so please
32 matches
Mail list logo
