Re: [PATCHES] Admin functions contrib
This logging issue has drained a lot of time during feature freeze when we should be getting existing patches in and completed. I am willing to apply a perfect patch but I am not willing to spend anymore time on this than I have to. This is all something that shouldn't be happening during feature freeze. I realize this patch is important to Andreas but every patch is important to its author. We have done just fine without this functionality for years so I don't see the rush to get it in. You can say Win32 will make it more significant, but if it doesn't work on Win32 yet, the argument doesn't work. And I am not going to apply a patch with the promise that a more complete one is coming later. I am not saying I am going to reject the patch if it arrives but I am not but I am not going to be upset if it doesn't make it in until 7.6. --- Andreas Pflug wrote: > Bruce Momjian wrote: > > Do people want the server file logging/rotating patch applied if it is > > Unix-only? Right now the patch is ifdef'ed so Win32 use of it is > > disabled. > > > > Andreas is asking. > > Please commit ASAP. Is I stated several times, I'll do the win32 as soon > as I get a chance to. It's not a logger file issue, it's a *win32 > stderr* problem. > > If you believe that a feature must support all systems, tablespace must > be removed as well. > > Regards, > Andreas > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 7: don't forget to increase your free space map settings
Re: [PATCHES] Admin functions contrib
Tom Lane wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. I'm slightly worried that we might be painting ourselves into a corner, ie implementing functionality that will never work on Windows. Personally, of course, I won't care if it never works on Windows. But I suspect there are some out there who do care ;-). It might be better to wait till we're sure there's a reasonable implementation path for Windows. Actually, I believe the implementation I did first (having all processes append to the logfile themselves) would have worked for win32 too. As long as you don't impose linux-centric limitations on win32 implementations, there certainly *are* solutions to the problem. A very reasonable way would be to have the win32_signal_waiter thread not only wait for the child terminating, but also checking the pipe. This is certainly *the* recommended win32 way. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Admin functions contrib
>> Do people want the server file logging/rotating patch applied if it is >> Unix-only? Right now the patch is ifdef'ed so Win32 use of it is >> disabled. I'm slightly worried that we might be painting ourselves into a corner, ie implementing functionality that will never work on Windows. Personally, of course, I won't care if it never works on Windows. But I suspect there are some out there who do care ;-). It might be better to wait till we're sure there's a reasonable implementation path for Windows. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Admin functions contrib
It's better than no patch I think. /D -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Sat 7/31/2004 5:33 AM To: Dave Page Cc: Tom Lane; Andreas Pflug; PostgreSQL Patches Subject: Re: [PATCHES] Admin functions contrib Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. --- Dave Page wrote: > > > > -Original Message- > > From: Tom Lane [mailto:[EMAIL PROTECTED] > > Sent: 29 July 2004 18:41 > > To: Andreas Pflug > > Cc: Bruce Momjian; PostgreSQL Patches; Dave Page > > Subject: Re: [PATCHES] Admin functions contrib > > > > Andreas Pflug <[EMAIL PROTECTED]> writes: > > > Bruce Momjian wrote: > > >> So, I suggest we get the logging code into the backend, > > and you can > > >> code anything you want pgadmin to do in plperlu, and Win32 > > supports > > >> plperlu too. The big advantage is that you can improve > > the plperlu > > >> functions with every release of pgadmin. > > > > > I do not agree on this. Administrative tools should require as few > > > additional backend packages as possible. > > > > This argument doesn't really hold water when the alternative > > is a contrib package. It's considerably more likely that the > > installation will have plperl than that it will have some > > random contrib package. > > > > Also, what happens if you find that the contrib package > > doesn't do everything you need? You'll be stuck for another > > PG release cycle, whereas rejiggering a plperl function that > > pgadmin is defining for itself is no problem. > > pgAdmin I used to create helper functions and views on the server, and > not only were they a *real* pain in the neck to manage, but they were > also the most often complained about 'feature' of pgAdmin, to the extent > that when pgAdmin II was written, rule number #1 was 'it must offer 100% > functionality on a clean, standard database with no server side > objects'. In pga1 it even got to the stage that I wrote a cleanup wizard > to allow ppl to remove the stuff that was created. We also had problems > with people who had limited access to their servers (because they were > ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for > the postgresql.org sites for example - I can't imagine the response I'd > get if I asked for pl/perlu!! > > This is primarily why we want to get the functionality into the backend. > Secondary to that, it will also allow phpPgAdmin and other tools to > offer the same functionality. It could be argued of course, that a > contrib module violates our standard database rule (which it does), but > it does at least allow us to get some standard code into the > distribution, in a way that /might/ be compatible with the feature > freeze, with a view to full integration in the next cycle. As Bruce has > seen, this is some pretty nice functionality that Andreas has added to > pga3, and is one of the few areas that we lag behind SQL Server etc. in > on the management front. > > Regards, Dave. > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Don't 'kill -9' the postmaster
Re: [PATCHES] Admin functions contrib
Peter Eisentraut wrote: Bruce Momjian wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. How is logging typically handled on Windows? It is done using the eventlog service (which is supported as replacement for syslog now) or in case of MSSQL as file logging. MSSQL in more detail: In eventlog only the most important MSSQL messages will appear (start/stop, PANIC), while the rest is done in logfiles (retrievable over client tools, rotatable using sp_cycle_errorlog) and may grow much larger than eventlog (which will receive messages from all apps/services). This handling is so throughout M$ apps, like webserver etc: fatals to eventlog, the rest to files. Regards, Andreas ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: > Do people want the server file logging/rotating patch applied if it > is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is > disabled. How is logging typically handled on Windows? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. Please commit ASAP. Is I stated several times, I'll do the win32 as soon as I get a chance to. It's not a logger file issue, it's a *win32 stderr* problem. If you believe that a feature must support all systems, tablespace must be removed as well. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Admin functions contrib
Do people want the server file logging/rotating patch applied if it is Unix-only? Right now the patch is ifdef'ed so Win32 use of it is disabled. Andreas is asking. --- Dave Page wrote: > > > > -Original Message- > > From: Tom Lane [mailto:[EMAIL PROTECTED] > > Sent: 29 July 2004 18:41 > > To: Andreas Pflug > > Cc: Bruce Momjian; PostgreSQL Patches; Dave Page > > Subject: Re: [PATCHES] Admin functions contrib > > > > Andreas Pflug <[EMAIL PROTECTED]> writes: > > > Bruce Momjian wrote: > > >> So, I suggest we get the logging code into the backend, > > and you can > > >> code anything you want pgadmin to do in plperlu, and Win32 > > supports > > >> plperlu too. The big advantage is that you can improve > > the plperlu > > >> functions with every release of pgadmin. > > > > > I do not agree on this. Administrative tools should require as few > > > additional backend packages as possible. > > > > This argument doesn't really hold water when the alternative > > is a contrib package. It's considerably more likely that the > > installation will have plperl than that it will have some > > random contrib package. > > > > Also, what happens if you find that the contrib package > > doesn't do everything you need? You'll be stuck for another > > PG release cycle, whereas rejiggering a plperl function that > > pgadmin is defining for itself is no problem. > > pgAdmin I used to create helper functions and views on the server, and > not only were they a *real* pain in the neck to manage, but they were > also the most often complained about 'feature' of pgAdmin, to the extent > that when pgAdmin II was written, rule number #1 was 'it must offer 100% > functionality on a clean, standard database with no server side > objects'. In pga1 it even got to the stage that I wrote a cleanup wizard > to allow ppl to remove the stuff that was created. We also had problems > with people who had limited access to their servers (because they were > ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for > the postgresql.org sites for example - I can't imagine the response I'd > get if I asked for pl/perlu!! > > This is primarily why we want to get the functionality into the backend. > Secondary to that, it will also allow phpPgAdmin and other tools to > offer the same functionality. It could be argued of course, that a > contrib module violates our standard database rule (which it does), but > it does at least allow us to get some standard code into the > distribution, in a way that /might/ be compatible with the feature > freeze, with a view to full integration in the next cycle. As Bruce has > seen, this is some pretty nice functionality that Andreas has added to > pga3, and is one of the few areas that we lag behind SQL Server etc. in > on the management front. > > Regards, Dave. > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: Fri 7/30/2004 5:34 PM To: Dave Page Cc: Tom Lane; Andreas Pflug; PostgreSQL Patches Subject: Re: [PATCHES] Admin functions contrib > Ouch, that is a powerful argument! The big problem is that we are > designing features a month after feature freeze. Not that the ideas > weren't around before feature freeze, but they are still not solid from > a community agreement perspective. Let's get the logging working and > then figure out what to do, OK? Sounds good to me :-) Regards, Dave ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Admin functions contrib
Dave Page wrote: > > Also, what happens if you find that the contrib package > > doesn't do everything you need? You'll be stuck for another > > PG release cycle, whereas rejiggering a plperl function that > > pgadmin is defining for itself is no problem. > > pgAdmin I used to create helper functions and views on the server, and > not only were they a *real* pain in the neck to manage, but they were > also the most often complained about 'feature' of pgAdmin, to the extent > that when pgAdmin II was written, rule number #1 was 'it must offer 100% > functionality on a clean, standard database with no server side > objects'. In pga1 it even got to the stage that I wrote a cleanup wizard > to allow ppl to remove the stuff that was created. We also had problems > with people who had limited access to their servers (because they were > ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for > the postgresql.org sites for example - I can't imagine the response I'd > get if I asked for pl/perlu!! > > This is primarily why we want to get the functionality into the backend. > Secondary to that, it will also allow phpPgAdmin and other tools to > offer the same functionality. It could be argued of course, that a > contrib module violates our standard database rule (which it does), but > it does at least allow us to get some standard code into the > distribution, in a way that /might/ be compatible with the feature > freeze, with a view to full integration in the next cycle. As Bruce has > seen, this is some pretty nice functionality that Andreas has added to > pga3, and is one of the few areas that we lag behind SQL Server etc. in > on the management front. Ouch, that is a powerful argument! The big problem is that we are designing features a month after feature freeze. Not that the ideas weren't around before feature freeze, but they are still not solid from a community agreement perspective. Let's get the logging working and then figure out what to do, OK? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
Andreas Pflug wrote: > Dave Page wrote: > > > As Bruce has seen, this is some pretty nice functionality that > > Andreas has added to pga3, and is one of the few areas that we > > lag behind SQL Server etc. in on the management front. > > > > If you're curious what Bruce has seen, it was this: > > http://www.pse-consulting.de/pgadmin3/pgadmin3-serverlog.png > > The size functions will offer this: > http://www.pse-consulting.de/pgadmin3/pgadmin3-tblspc-stat.png Yep, that's what I saw. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Admin functions contrib
Dave Page wrote: As Bruce has seen, this is some pretty nice functionality that > Andreas has added to pga3, and is one of the few areas that we > lag behind SQL Server etc. in on the management front. If you're curious what Bruce has seen, it was this: http://www.pse-consulting.de/pgadmin3/pgadmin3-serverlog.png The size functions will offer this: http://www.pse-consulting.de/pgadmin3/pgadmin3-tblspc-stat.png Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Admin functions contrib
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED] > Sent: 29 July 2004 18:41 > To: Andreas Pflug > Cc: Bruce Momjian; PostgreSQL Patches; Dave Page > Subject: Re: [PATCHES] Admin functions contrib > > Andreas Pflug <[EMAIL PROTECTED]> writes: > > Bruce Momjian wrote: > >> So, I suggest we get the logging code into the backend, > and you can > >> code anything you want pgadmin to do in plperlu, and Win32 > supports > >> plperlu too. The big advantage is that you can improve > the plperlu > >> functions with every release of pgadmin. > > > I do not agree on this. Administrative tools should require as few > > additional backend packages as possible. > > This argument doesn't really hold water when the alternative > is a contrib package. It's considerably more likely that the > installation will have plperl than that it will have some > random contrib package. > > Also, what happens if you find that the contrib package > doesn't do everything you need? You'll be stuck for another > PG release cycle, whereas rejiggering a plperl function that > pgadmin is defining for itself is no problem. pgAdmin I used to create helper functions and views on the server, and not only were they a *real* pain in the neck to manage, but they were also the most often complained about 'feature' of pgAdmin, to the extent that when pgAdmin II was written, rule number #1 was 'it must offer 100% functionality on a clean, standard database with no server side objects'. In pga1 it even got to the stage that I wrote a cleanup wizard to allow ppl to remove the stuff that was created. We also had problems with people who had limited access to their servers (because they were ISP hosted etc). I've not even persuaded hub.org to install pl/pgsql for the postgresql.org sites for example - I can't imagine the response I'd get if I asked for pl/perlu!! This is primarily why we want to get the functionality into the backend. Secondary to that, it will also allow phpPgAdmin and other tools to offer the same functionality. It could be argued of course, that a contrib module violates our standard database rule (which it does), but it does at least allow us to get some standard code into the distribution, in a way that /might/ be compatible with the feature freeze, with a view to full integration in the next cycle. As Bruce has seen, this is some pretty nice functionality that Andreas has added to pga3, and is one of the few areas that we lag behind SQL Server etc. in on the management front. Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: If it's not going into the distribution as contrib or core, I'll package that as additional admin pack. I'm quite sure I can convince the win32 installer packager guys to include that as default-on option as soon as I'm able to prove them how it's working. Uh, but it isn't working on Win32, right? How do you fix that? During beta? That would be OK as an add-on. As I said, I'm going to fix the stderr issue. This will enable the pending log rotation stuff more or less incidentially. The win32 log issue isn't a serverlog rotation issue, as I stated also the current stderr output is affected! I'd clearly see that as a fix, whilst it might be more than 10 lines of code. I'll try to fix that tomorrow. The very log_destination=file and rotation code will be more or less the same as for ***x. But does it work on Win32 and Unix? It has to. I meant to implement that stderr handling stuff for win32, in order to have a clean stderr output. Unix isn't affected, it works as posted. Yes, that is a problem but we have to cut or we will never get to beta. Probably doing an add-on until 7.6 might be the best but you are working on it so let's see. The add-on are the functions, not the log rotation. Log rotation for unix is beta-ready, and virtually unchanged for weeks now. It will be available shortly for win32 too, as soon as the stderr piping issue is solved. I'm a bit tired of arguing, that's why I didn't split the functions in a part that was proposed together with the core functionality before feature freeze and an additional part. I feel that the majority of installations (win32) will have them anyway. Regards, Andreas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Admin functions contrib
Andreas Pflug <[EMAIL PROTECTED]> writes: > Bruce Momjian wrote: >> So, I suggest we get the logging code into the backend, and you can code >> anything you want pgadmin to do in plperlu, and Win32 supports plperlu >> too. The big advantage is that you can improve the plperlu functions >> with every release of pgadmin. > I do not agree on this. Administrative tools should require as few > additional backend packages as possible. This argument doesn't really hold water when the alternative is a contrib package. It's considerably more likely that the installation will have plperl than that it will have some random contrib package. Also, what happens if you find that the contrib package doesn't do everything you need? You'll be stuck for another PG release cycle, whereas rejiggering a plperl function that pgadmin is defining for itself is no problem. I think that developing with plperl for a few months would be a good path, because then you would have some actual field experience under your belt to justify the specific design of the contrib or core backend functions you want. Right now they look mighty scattershot. > It won't generate trust if pgadmin documentation advises "install > untrusted plperl to maintain your machine". Nonsense. You are already expecting these people to give you superuser access, no? They had better trust you already. (Actually, you wouldn't even have to ask them --- you could just create plperlu for yourself --- but I suppose that would seem impolite.) > I posted this stuff as contrib > module to keep it off the feature freeze issue. Contrib does not have an exception for the feature freeze rule. It's a little looser maybe but that doesn't mean we'll accept an entire new module after freeze. > Reimplementing it as plperlu is crap. I'm sorry you feel that way. It seemed like a fairly attractive alternative to me, especially for early development. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Admin functions contrib
Andreas Pflug wrote: > Bruce Momjian wrote: > > > > > Basically I think we are converging on an answer that we can't do any of > > this for 7.5. > > If it's not going into the distribution as contrib or core, I'll package > that as additional admin pack. I'm quite sure I can convince the win32 > installer packager guys to include that as default-on option as soon as > I'm able to prove them how it's working. Uh, but it isn't working on Win32, right? How do you fix that? During beta? That would be OK as an add-on. > > The scope has gone way beyond what we had at feature > > freeze, and we can't even get it to work on Win32, > > ??? The functions will work for win32, are you talking about logging? I mean logging. > The win32 log issue isn't a serverlog rotation issue, as I stated also > the current stderr output is affected! I'd clearly see that as a fix, > whilst it might be more than 10 lines of code. I'll try to fix that > tomorrow. The very log_destination=file and rotation code will be more > or less the same as for ***x. But does it work on Win32 and Unix? It has to. > > I have added this to the TODO list: > > > > * Allow server logs to be read using SQL commands > > * Allow server configuration parameters to be modified remotetly > > This is desirable in any case. But until 7.6 will be around, 1-1.5 years > and ???,000 installations will happen. Since the functionality is > available now or will be available VSN (certainly before 7.5 release), > there's no good reason suppress it. Yes, that is a problem but we have to cut or we will never get to beta. Probably doing an add-on until 7.6 might be the best but you are working on it so let's see. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: 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: [PATCHES] Admin functions contrib
Bruce Momjian wrote: Basically I think we are converging on an answer that we can't do any of this for 7.5. If it's not going into the distribution as contrib or core, I'll package that as additional admin pack. I'm quite sure I can convince the win32 installer packager guys to include that as default-on option as soon as I'm able to prove them how it's working. The scope has gone way beyond what we had at feature freeze, and we can't even get it to work on Win32, ??? The functions will work for win32, are you talking about logging? The win32 log issue isn't a serverlog rotation issue, as I stated also the current stderr output is affected! I'd clearly see that as a fix, whilst it might be more than 10 lines of code. I'll try to fix that tomorrow. The very log_destination=file and rotation code will be more or less the same as for ***x. I have added this to the TODO list: * Allow server logs to be read using SQL commands * Allow server configuration parameters to be modified remotetly This is desirable in any case. But until 7.6 will be around, 1-1.5 years and ???,000 installations will happen. Since the functionality is available now or will be available VSN (certainly before 7.5 release), there's no good reason suppress it. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
Andreas Pflug wrote: > > So, I suggest we get the logging code into the backend, and you can code > > anything you want pgadmin to do in plperlu, and Win32 supports plperlu > > too. The big advantage is that you can improve the plperlu functions > > with every release of pgadmin. > > I do not agree on this. Administrative tools should require as few > additional backend packages as possible. What you're proposing is simply > a nightmare. Actually, IMHO all functions should be *backend* code, not > contrib code, even less arbitrary loadable language functions. Certainly > an external package relying on a loadable language is quite the > opposite, generating lots of support issues. It won't generate trust if > pgadmin documentation advises "install untrusted plperl to maintain your > machine". > Additionally, several of the functions are by no means new, but > replacements, did you notice pg_xxx_size? I posted this stuff as contrib > module to keep it off the feature freeze issue. If it still can't go > there, it must stay an external module which will be distributed as > pgadmin add-on. Reimplementing it as plperlu is crap. Well, if plperlu was always compiled by default we would be OK. If it isn't then you are right it would be a problem. I see the --with-perl option to configure so you are right it might be a problem. Basically I think we are converging on an answer that we can't do any of this for 7.5. The scope has gone way beyond what we had at feature freeze, and we can't even get it to work on Win32, which was one of the big goals for easier Win32 administration, so I think we should just shelve all this and get it right for 7.6 when we have time to address this. I have added this to the TODO list: * Allow server logs to be read using SQL commands * Allow server configuration parameters to be modified remotetly -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Admin functions contrib
Bruce Momjian wrote: I talked to Tom about this today. First, I want to apologize for running you around in circles in this. I don't think we are giving it the attention it needs because of our schedule. I also think the functionality is drifting into the "new features" territory and this is also part of the delay you are seeing. I think you did a great thing by breaking the patch into two parts: one for logging, and the other for log reading and other stuff. The logging part is already in the patch queue. As for the function below, I first think the security issue brough up about them wasn't a valid concern because as I stated someone could just load the plperl server-side language and do anything to the OS. In fact this might be the best solution for you. Instead of trying to code read/write/rename/unlink and other functions into the backend as hardcoded, why not just have pgadmin load plperlu and as the super-user you have access to that functionality, and much more, especially with the new plperl in 7.5. In fact, your goal of modifying the postgresql.conf file is much more natural in perl than in the API you supplied, and probably more reliable. So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. I do not agree on this. Administrative tools should require as few additional backend packages as possible. What you're proposing is simply a nightmare. Actually, IMHO all functions should be *backend* code, not contrib code, even less arbitrary loadable language functions. Certainly an external package relying on a loadable language is quite the opposite, generating lots of support issues. It won't generate trust if pgadmin documentation advises "install untrusted plperl to maintain your machine". Additionally, several of the functions are by no means new, but replacements, did you notice pg_xxx_size? I posted this stuff as contrib module to keep it off the feature freeze issue. If it still can't go there, it must stay an external module which will be distributed as pgadmin add-on. Reimplementing it as plperlu is crap. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Admin functions contrib
I talked to Tom about this today. First, I want to apologize for running you around in circles in this. I don't think we are giving it the attention it needs because of our schedule. I also think the functionality is drifting into the "new features" territory and this is also part of the delay you are seeing. I think you did a great thing by breaking the patch into two parts: one for logging, and the other for log reading and other stuff. The logging part is already in the patch queue. As for the function below, I first think the security issue brough up about them wasn't a valid concern because as I stated someone could just load the plperl server-side language and do anything to the OS. In fact this might be the best solution for you. Instead of trying to code read/write/rename/unlink and other functions into the backend as hardcoded, why not just have pgadmin load plperlu and as the super-user you have access to that functionality, and much more, especially with the new plperl in 7.5. In fact, your goal of modifying the postgresql.conf file is much more natural in perl than in the API you supplied, and probably more reliable. So, I suggest we get the logging code into the backend, and you can code anything you want pgadmin to do in plperlu, and Win32 supports plperlu too. The big advantage is that you can improve the plperlu functions with every release of pgadmin. --- Andreas Pflug wrote: > These files add administrative functions to pgsql 7.5. All are used by > pgAdmin3 or will be used in the near future if available. This is meant > as contrib module, whilst IMHO all these functions should be integrated > into the backend. > > Included are functions to > > log file access > These where previously posted together with the logger subprocess patch > and might get committed to the backend code. > > misc. > send SIGHUP to postmaster > > generic file access functions > These are more restrictive than the previously posted: Write access is > necessary for files to rename and unlink, and paths are restricted to > PGDATA and the logdir. > > size functions > These are 7.5 replacements for dbsize. > > Regards, > Andreas > subdir = contrib/admin > top_builddir = ../.. > include $(top_builddir)/src/Makefile.global > > MODULE_big = admin > DATA_built = admin.sql > DOCS = README.admin > OBJS = size.o genfile.o misc.o > include $(top_srcdir)/contrib/contrib-global.mk > /* ** > * Administrative functions > * * */ > > /* database object size functions (admin.c) */ > > CREATE FUNCTION pg_tablespace_size(oid) RETURNS bigint > AS 'MODULE_PATHNAME', 'pg_tablespace_size' > LANGUAGE C STABLE STRICT; > > CREATE FUNCTION pg_database_size(oid) RETURNS bigint > AS 'MODULE_PATHNAME', 'pg_database_size' > LANGUAGE C STABLE STRICT; > > CREATE FUNCTION pg_relation_size(oid) RETURNS bigint > AS 'MODULE_PATHNAME', 'pg_relation_size' > LANGUAGE C STABLE STRICT; > > CREATE FUNCTION pg_size_pretty(bigint) RETURNS text > AS 'MODULE_PATHNAME', 'pg_size_pretty' > LANGUAGE C STABLE STRICT; > > > /* generic file access functions (genfile.c) */ > > CREATE FUNCTION pg_file_stat(text) RETURNS record >AS 'MODULE_PATHNAME', 'pg_file_stat' > LANGUAGE C VOLATILE STRICT; > > CREATE FUNCTION pg_file_length(text) RETURNS bigint >AS 'SELECT len FROM pg_file_stat($1) AS s(len int8, c timestamp, a timestamp, m > timestamp, i bool)' > LANGUAGE SQL VOLATILE STRICT; > > CREATE FUNCTION pg_file_read(text, bigint, bigint) RETURNS text >AS 'MODULE_PATHNAME', 'pg_file_read' > LANGUAGE C VOLATILE STRICT; > > CREATE FUNCTION pg_file_write(text, text, bool) RETURNS bigint >AS 'MODULE_PATHNAME', 'pg_file_write' > LANGUAGE C VOLATILE STRICT; > > CREATE FUNCTION pg_file_rename(text, text, text) RETURNS bool >AS 'MODULE_PATHNAME', 'pg_file_rename' > LANGUAGE C VOLATILE STRICT; > > CREATE FUNCTION pg_file_unlink(text) RETURNS bool >AS 'MODULE_PATHNAME', 'pg_file_unlink' > LANGUAGE C VOLATILE STRICT; > > CREATE FUNCTION pg_file_rename(text, text) RETURNS bool >AS 'SELECT pg_file_rename($1, $2, NULL); ' > LANGUAGE SQL VOLATILE STRICT; > > CREATE FUNCTION pg_dir_ls(text, bool) RETURNS setof text >AS 'MODULE_PATHNAME', 'pg_dir_ls' > LANGUAGE C VOLATILE STRICT; > > > /* Miscellaneous functions (misc.c) */ > > CREATE FUNCTION pg_reload_conf() RETURNS int4 >AS 'MODULE_PATHNAME', 'pg_reload_conf' > LANGUAGE C STABLE STRICT; > > CREATE FUNCTION pg_logfile_rotate() RETURNS bool >AS 'MODULE_PATHNAME', 'pg_logfile_rotate' > LANGUAGE C STABLE STRICT; > > CREATE FUNCTION pg_logdir_ls() RETURNS setof record >AS 'MODULE_PATHNAME', 'pg_logdir_ls' > LANGUAGE C VOLATILE STRICT; > > CREATE VIEW pg_logdir_ls AS > SELECT * > FROM pg_logdir_ls() AS A >
[PATCHES] Admin functions contrib
These files add administrative functions to pgsql 7.5. All are used by
pgAdmin3 or will be used in the near future if available. This is meant
as contrib module, whilst IMHO all these functions should be integrated
into the backend.
Included are functions to
log file access
These where previously posted together with the logger subprocess patch
and might get committed to the backend code.
misc.
send SIGHUP to postmaster
generic file access functions
These are more restrictive than the previously posted: Write access is
necessary for files to rename and unlink, and paths are restricted to
PGDATA and the logdir.
size functions
These are 7.5 replacements for dbsize.
Regards,
Andreas
subdir = contrib/admin
top_builddir = ../..
include $(top_builddir)/src/Makefile.global
MODULE_big = admin
DATA_built = admin.sql
DOCS = README.admin
OBJS = size.o genfile.o misc.o
include $(top_srcdir)/contrib/contrib-global.mk
/* **
* Administrative functions
* * */
/* database object size functions (admin.c) */
CREATE FUNCTION pg_tablespace_size(oid) RETURNS bigint
AS 'MODULE_PATHNAME', 'pg_tablespace_size'
LANGUAGE C STABLE STRICT;
CREATE FUNCTION pg_database_size(oid) RETURNS bigint
AS 'MODULE_PATHNAME', 'pg_database_size'
LANGUAGE C STABLE STRICT;
CREATE FUNCTION pg_relation_size(oid) RETURNS bigint
AS 'MODULE_PATHNAME', 'pg_relation_size'
LANGUAGE C STABLE STRICT;
CREATE FUNCTION pg_size_pretty(bigint) RETURNS text
AS 'MODULE_PATHNAME', 'pg_size_pretty'
LANGUAGE C STABLE STRICT;
/* generic file access functions (genfile.c) */
CREATE FUNCTION pg_file_stat(text) RETURNS record
AS 'MODULE_PATHNAME', 'pg_file_stat'
LANGUAGE C VOLATILE STRICT;
CREATE FUNCTION pg_file_length(text) RETURNS bigint
AS 'SELECT len FROM pg_file_stat($1) AS s(len int8, c timestamp, a timestamp, m
timestamp, i bool)'
LANGUAGE SQL VOLATILE STRICT;
CREATE FUNCTION pg_file_read(text, bigint, bigint) RETURNS text
AS 'MODULE_PATHNAME', 'pg_file_read'
LANGUAGE C VOLATILE STRICT;
CREATE FUNCTION pg_file_write(text, text, bool) RETURNS bigint
AS 'MODULE_PATHNAME', 'pg_file_write'
LANGUAGE C VOLATILE STRICT;
CREATE FUNCTION pg_file_rename(text, text, text) RETURNS bool
AS 'MODULE_PATHNAME', 'pg_file_rename'
LANGUAGE C VOLATILE STRICT;
CREATE FUNCTION pg_file_unlink(text) RETURNS bool
AS 'MODULE_PATHNAME', 'pg_file_unlink'
LANGUAGE C VOLATILE STRICT;
CREATE FUNCTION pg_file_rename(text, text) RETURNS bool
AS 'SELECT pg_file_rename($1, $2, NULL); '
LANGUAGE SQL VOLATILE STRICT;
CREATE FUNCTION pg_dir_ls(text, bool) RETURNS setof text
AS 'MODULE_PATHNAME', 'pg_dir_ls'
LANGUAGE C VOLATILE STRICT;
/* Miscellaneous functions (misc.c) */
CREATE FUNCTION pg_reload_conf() RETURNS int4
AS 'MODULE_PATHNAME', 'pg_reload_conf'
LANGUAGE C STABLE STRICT;
CREATE FUNCTION pg_logfile_rotate() RETURNS bool
AS 'MODULE_PATHNAME', 'pg_logfile_rotate'
LANGUAGE C STABLE STRICT;
CREATE FUNCTION pg_logdir_ls() RETURNS setof record
AS 'MODULE_PATHNAME', 'pg_logdir_ls'
LANGUAGE C VOLATILE STRICT;
CREATE VIEW pg_logdir_ls AS
SELECT *
FROM pg_logdir_ls() AS A
(filetime timestamp, pid int4, filename text);
/*-
*
* genfile.c
*
*
* Copyright (c) 2004, PostgreSQL Global Development Group
*
* Author: Andreas Pflug <[EMAIL PROTECTED]>
*
* IDENTIFICATION
* $PostgreSQL: $
*
*-
*/
#include "postgres.h"
#include
#include
#include
#include "miscadmin.h"
#include "storage/fd.h"
#include "catalog/pg_type.h"
#include "funcapi.h"
Datum pg_file_stat(PG_FUNCTION_ARGS);
Datum pg_file_read(PG_FUNCTION_ARGS);
Datum pg_file_write(PG_FUNCTION_ARGS);
Datum pg_file_rename(PG_FUNCTION_ARGS);
Datum pg_file_unlink(PG_FUNCTION_ARGS);
Datum pg_dir_ls(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(pg_file_stat);
PG_FUNCTION_INFO_V1(pg_file_read);
PG_FUNCTION_INFO_V1(pg_file_write);
PG_FUNCTION_INFO_V1(pg_file_rename);
PG_FUNCTION_INFO_V1(pg_file_unlink);
PG_FUNCTION_INFO_V1(pg_dir_ls);
extern char *Log_directory;
typedef struct
{
char *location;
DIR *dirdesc;
} directory_fctx;
/*---
* some helper functions
*/
/*
* Return an absolute path. Argument may be absolute or
* relative to the DataDir.
*/
static char *absClusterPath(text *arg, bool logAllowed)
{
char *filename;
int len=VARSIZE(arg) - VARHDRSZ;
int dlen = strlen(DataDir);
filename = palloc(len+1);
memcpy(filename, VARDATA(arg), len);
filename[len] = 0;
if (strstr(filename, "..") != NULL)
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
(errmsg("No .. allowed in filenames";
if (is_absolute_path(filename))
{
if (logAllowed && !strncmp(filename, Log_directory, strl
