Re: [HACKERS] Remote administration functionality
-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 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 vi? Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remote administration functionality
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
Re: [HACKERS] Remote administration functionality
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 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 vi? I don't see any way to fix that. The hope is that the administrator has enough control that this isn't happenening --- it could already happen now if who people edit the same file with different editors/locking systems. -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Remote administration functionality
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 vi? I don't see any way to fix that. The hope is that the administrator has enough control that this isn't happenening --- it could already happen now if who people edit the same file with different editors/locking systems. 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*. 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? //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remote administration functionality
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
Re: [HACKERS] Remote administration functionality
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. I am not sure how remote restart would work. Remote reboot to change shared_buffers and other shmem-sizing parameters seems pretty doable: all you need is a slightly more user-friendly version of the standard response to backend crash, since that sequence already kills and recreates the shmem segment. The postmaster itself doesn't have to change anything. Let's consider what to do if the new shmem size is bigger than the current value, and the new value exceeds kernel limits. How can we measure that in advance? Maybe create a new segment, sized as the difference between new and old; then destroy both and recreate the new, bigger one. It doesn't strike me as super straightforward. Are we prepared to rollback to a known-safe value? -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) Los dioses no protegen a los insensatos. Éstos reciben protección de otros insensatos mejor dotados (Luis Wu, Mundo Anillo) ---(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
Re: [HACKERS] Remote administration functionality
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 editting pg_hba.conf in vi? I don't see any way to fix that. The hope is that the administrator has enough control that this isn't happenening --- it could already happen now if who people edit the same file with different editors/locking systems. 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() function load the file into a temporary table, which can then be modified and flushed down to the flat file. Another option is that queries to the table automatically read the flat file, but that might force writes to the file on first update, so that might be bad. 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 using columns for the pg_hba.conf lines (except for comments), we are making it somewhat easier. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Remote administration functionality
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
Re: [HACKERS] Remote administration functionality
-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 pg_hba.conf lines (except for comments), we are making it somewhat easier. I fail to see a real use-case for somebody editing pg_hba.conf *by hand* using this. I can see it happening through a tool like phppgadmin or pgadmin, in which case this will actually make it *harder* to implement. Agreed. Regards, Dave ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Remote administration functionality
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() function load the file into a temporary table, which can then be modified and flushed down to the flat file. Another option is that queries to the table automatically read the flat file, but that might force writes to the file on first update, so that might be bad. That would be very bad. You can only flush at controlled times. 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 using columns for the pg_hba.conf lines (except for comments), we are making it somewhat easier. I fail to see a real use-case for somebody editing pg_hba.conf *by hand* using this. I can see it happening through a tool like phppgadmin or pgadmin, in which case this will actually make it *harder* to implement. //Magnus ---(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
Re: [HACKERS] Remote administration functionality
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
Re: [HACKERS] Remote administration functionality
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 file. You could make the patching fail if anything doesn't match and force the client to re-diff the file and send a new patch if it doesn't match exactly. Quite a large increase in complexity, but at least the window of opportunity that it has to go wrong would be vastly reduced. Plus you can do whatever operating specific locking on the file is appropiate while the update is in progress without needing to expose anything to the client. This is sounding more like a job for something external to Postgres and you just need some way of telling Postgres that it needs to reload the appropiate config file though. Sam ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Remote administration functionality
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 signature.asc Description: Digital signature
Re: [HACKERS] Remote administration functionality
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 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
Re: [HACKERS] Remote administration functionality
-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, 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 :). Because the admin doesn't edit pg_shadow using vi or some other editor, and then possibly forget to tell the postmaster to reload it before someone else writes a new copy via the server. Regards, Dave. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Remote administration functionality
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 the situation where dba #1 updates the pg_hba table, at the same time as dba #2 is editting pg_hba.conf in vi? Don't do that then. With this change, editing ph_hba.conf by hand should only be done when the database is down... -Doug ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Remote administration functionality
-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 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 the situation where dba #1 updates the pg_hba table, at the same time as dba #2 is editting pg_hba.conf in vi? Don't do that then. With this change, editing ph_hba.conf by hand should only be done when the database is down... Don't tell me, tell all the users that log bugs when their changes get lost because they didn't read that bit of the manual for whatever version this might or might not end up in :-). People are used to editting the file and hupping the server, and I would guess few of us existing users re-read the pg_hba.conf manual pages when setting up our shiny new version. Regards, Dave. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remote administration functionality
* 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 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 signature.asc Description: Digital signature
Re: [HACKERS] Remote administration functionality
-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 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 location and renamed. Otherwise people would be bound to try to edit it as that is what they have done for years. Regards, Dave. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Remote administration functionality
* 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 location and renamed. Otherwise people would be bound to try to edit it as that is what they have done for years. Sure, it could be moved/renamed to avoid confusion. Seems like alot better than having the database try to deal with user-editable files, which are in a format that's intended to be user-editable though. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Remote administration functionality
* 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 editor, and then possibly forget to tell the postmaster to reload it before someone else writes a new copy via the server. 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. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Remote administration functionality
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 better having the load() function load the file into a temporary table, which can then be modified and flushed down to the flat file. Another option is that queries to the table automatically read the flat file, but that might force writes to the file on first update, so that might be bad. That would be very bad. You can only flush at controlled times. Right. 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 using columns for the pg_hba.conf lines (except for comments), we are making it somewhat easier. I fail to see a real use-case for somebody editing pg_hba.conf *by hand* using this. I can see it happening through a tool like phppgadmin or pgadmin, in which case this will actually make it *harder* to implement. Uh, not sure why it would be harder. What system would be easier? Sure, file I/O works, but you can't even try to do that from psql. -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Remote administration functionality
-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 easier? Sure, file I/O works, but you can't even try to do that from psql. In pgAdmin we would need to track all the changes the user makes to the file, and generate all the appropriate insert, update and delete queries to make the server match what the user wants. With file IO, we just let the user edit, then send the resulting file in one select statement. WRT to doing it in psql, the average psql user is probably the same person that would prefer to use vi or emacs to do the job anyway. /D ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Remote administration functionality
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 using columns for the pg_hba.conf lines (except for comments), we are making it somewhat easier. I fail to see a real use-case for somebody editing pg_hba.conf *by hand* using this. I can see it happening through a tool like phppgadmin or pgadmin, in which case this will actually make it *harder* to implement. Uh, not sure why it would be harder. What system would be easier? Sure, file I/O works, but you can't even try to do that from psql. Doing it from psql is the part I fail to see a real use-case for. The people who would use psql for it would probably just use vi or emacs or sed or whatever on the file itself. If you needed to do it remotely, you could just call pqsl once to get the data out to a local file, edit that file, and then call it again to put it back on the server, no? //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] psql as an execve(2) interpreter
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 is right, it is much more valuable and supportable to call psql from within a shell script than add the functionality to psql itself. I, too, have thought a lot about this and I suppose we are reaching different conclusions. I would very much appreciate hearing your logic, as the underlying reasoning you imply is not transparent to me. For what it is worth, here is an outline of part of my thinking. It is true that the nature of SQL as a language is different from other traditional programming languages, as it does not have concepts such as variables and flow control. To my way of thinking, however, that simply dictates what is possible to express in the language. Importantly, I do not see how it influences how one might wish to execute the commands given in the language (or any language for that matter). In my mind the decision about how to execute something is based on what it does and what the larger context is, not what the language can express. Suppose I have a script S in some language L that is interpretable by some interpreter I. The language L might be SQL and the inrepreter I might be psql, but nothing that follows depends on that. Indeed, the language could be perl and the interpreter perl. The fundamental questions are: - What are useful ways to have the interpreter I carry out the instructions contained within S? - What determines why those are useful? - How can those means be achieved? For most scripting languages L (e.g., shell commands, perl, etc.) the prior art has identified two useful means of having the interpreter execute the instructions in S: 1) explicit execution (i.e., execute the interpreter and explicitly pass the appropriate script S to it) and 2) implicit execution (i.e., execute the script and magically have the system invoke the interpreter on it). Interpreting SQL scripts stands out as one exception to this. Why would one choose one method over another? In all cases that I can think of, the decision to use one method over another depends entirely on considerations that are external to the nature of the language L itself. I would venture to say that they are governed primarily by the nature of the external interface one is trying to create. In some cases, depending on what the script actually does, it is much more natural to invoke a script directly. An example would be one that is a wrapper to something else, but must take the responsibility for setting up the environment first. In other cases, the other mechanism is more natural. The decision does not bear on what the _language_ is capable of expressing, but rather on what the particular script is doing and how it fits into a larger external context. In my mind, the same is true for SQL. In some cases it is appropriate to execute the interpreter (i.e., psql) explicitly (that is currently our only option). In other cases it is appropriate to execute it implicitly. I see no fundamental difference between this and any other interpreter. Clearly, an implicit execution mechanism for SQL cannot work quite as transparently as for languages that use the hash mark (#) as a comment introducer. However, supporting this option need not interfere with other uses of the interpreter nor need it be costly. What is required is 1) a command line option that differentiates traditional behavior from the implicit interpreter behavior, and 2) a modification of how the first line of the file is handled depending on the mode. No other changes are required; no interaction with the vast majority of the code is needed. Thus, my analysis suggests no fundamental difference between the set of invocations that are useful for the majority of interpreters and the set that would be useful for interpreters of SQL. I also can envision a means of expanding that set for psql that would have no impact on either its normal use or its ongoing maintenance and development. Consequently, I see no compelling reason not to move in this direction. However, I must be missing something obvious, as there seems to be conflicting sentiment. I would be very interested to learn more about what is behind those ideas. Cheers, Brook ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] #escape_string_warning = off
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 - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] #escape_string_warning = off
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 planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Autovacuum to-do list
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 working ok. I am planning on doing some more in depth tests this week. * 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 vacuum automatically throttle down when the system gets busy and throttle back up when the system gets quiet. We would probably set some min / max values but it sounds interesting, thoughts? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Autovacuum to-do list
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 vacuum automatically throttle down when the system gets busy and throttle back up when the system gets quiet. We would probably set some min / max values but it sounds interesting, thoughts? I'd be very concerned about feedback loop stability; insufficient vacuuming can increase the system load, causing vacuum to get further behind... -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Autovacuum to-do list
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 this would have the effect of having vacuum automatically throttle down when the system gets busy and throttle back up when the system gets quiet. We would probably set some min / max values but it sounds interesting, thoughts? I'd be very concerned about feedback loop stability; insufficient vacuuming can increase the system load, causing vacuum to get further behind... Right which is why we would need to enforce some max value so that vacuuming will never be totally squeezed out. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Autovacuum to-do list
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 determine load average on win32? regards, J ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Autovacuum to-do list
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 forgive my ignorance, but is it even possible to determine load average on win32? Oooo... That's a lot of win32 ignorance to ignore... :-) Push control-alt-delete and look under Performance. I believe Windows may even keep *more* information that Linux. It's all a question of figuring out what the Win32 API calls are to get what you are looking for. Most concepts found in one system are also found in the other. I would assume yes before no. Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
