Thread: running script on server shutdown (TODO)
I've written a small patch for following TODO item: «Add GUC variable to run a command on database panic or smart/fast/immediate shutdown.» It adds two GUC variables as: enable_atexit_script_file atexit_script_file postmaster will run related script file with passing shutdown type (like "smart", "fast" or "immediate") as parameter to script file on database shutdown. (Sorry, I'm not so good on PostgreSQL internals, thus couldn't handle "panic" situation at the moment.) I know, it's not the perfect one but I'd be so apprecited to hear suggestions for fixing lost/wrong parts of it. Regards. -- "We are the middle children of history, raised by television to believe that someday we'll be millionaires and movie stars and rock stars, but we won't. And we're just learning this fact," Tyler said. "So don't fuck with us."
Attachment
Volkan YAZICI <yazicivo@ttnet.net.tr> writes:
> I've written a small patch for following TODO item:
> �Add GUC variable to run a command on database
> panic or smart/fast/immediate shutdown.�
I'm not sure why this is in TODO; it's a stupid if not outright
dangerous idea. Quite aside from any security considerations,
the time the script takes is taken away from the time available
to shut down the database before the kernel takes matters into
its own hands.
Besides, what is the point? Whatever you need to do can be incorporated
into the initscript you use to start up or shut down the postmaster.
I see no need for this functionality to be inside the postmaster.
regards, tom lane
Tom Lane said: > > I'm not sure why this is in TODO; it's a stupid if not outright > dangerous idea. I agree, in this case ... BUT ... This is what bothers me about having such an informal TODO list. There is a danger that people will work in items only to have them shot down, which is a great way to turn off developers. And there is also a danger that other people will think that the todo item is likely to be accepted at some stage. cheers andrew
"Andrew Dunstan" <andrew@dunslane.net> writes:
> This is what bothers me about having such an informal TODO list. There is a
> danger that people will work in items only to have them shot down, which is
> a great way to turn off developers. And there is also a danger that other
> people will think that the todo item is likely to be accepted at some stage.
I've complained to Bruce about that before --- there are a number of items
on TODO that only one person thinks is a good idea.
Perhaps some sort of [controversial] marker would be useful to warn
people that the item needs more discussion before going off in a corner
and trying to implement it.
regards, tom lane
On 12/10/05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Andrew Dunstan" <andrew@dunslane.net> writes: > > This is what bothers me about having such an informal TODO list. There is > a > > danger that people will work in items only to have them shot down, which > is > > a great way to turn off developers. And there is also a danger that other > > people will think that the todo item is likely to be accepted at some > stage. > > I've complained to Bruce about that before --- there are a number of items > on TODO that only one person thinks is a good idea. > > Perhaps some sort of [controversial] marker would be useful to warn > people that the item needs more discussion before going off in a corner > and trying to implement it. > > regards, tom lane > Actually some items are marked with a '?' that shows that that item needs discussion... although that it's not clearly stated in no where in the TODO... Maybe be explicit about what the '?' mark means and mark every new item with it until there is concensus a on it -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;)
Tom Lane wrote:
> "Andrew Dunstan" <andrew@dunslane.net> writes:
> > This is what bothers me about having such an informal TODO list. There is a
> > danger that people will work in items only to have them shot down, which is
> > a great way to turn off developers. And there is also a danger that other
> > people will think that the todo item is likely to be accepted at some stage.
>
> I've complained to Bruce about that before --- there are a number of items
> on TODO that only one person thinks is a good idea.
>
> Perhaps some sort of [controversial] marker would be useful to warn
> people that the item needs more discussion before going off in a corner
> and trying to implement it.
Well, the item was added at the request of Peter Eisentraut and Martijn
van Oosterhout and took place on hackers. The TODO addition was posted
too:
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00333.php
Not sure what else can be done to improve this process. I will remove
the TODO item.
And our developer TODO has:
<H3 id="item1.4">1.4) What do I do after choosing an item to
work on?</H3>
<P>Send an email to pgsql-hackers with a proposal for what you want
to do (assuming your contribution is not trivial). Working in
isolation is not advisable because others might be working on the asame
TODO item, or you might have misunderstood the TODO item. In the
email, discuss both the internal implementation method you plan to
use, and any user-visible changes (new syntax, etc). For complex
patches, it is important to get community feeback on your proposal
before starting work. Failure to do so might mean your patch is
rejected.</P>
So I think we are covered there too.
--
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
Jaime Casanova wrote: > On 12/10/05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > "Andrew Dunstan" <andrew@dunslane.net> writes: > > > This is what bothers me about having such an informal TODO list. There is > > a > > > danger that people will work in items only to have them shot down, which > > is > > > a great way to turn off developers. And there is also a danger that other > > > people will think that the todo item is likely to be accepted at some > > stage. > > > > I've complained to Bruce about that before --- there are a number of items > > on TODO that only one person thinks is a good idea. > > > > Perhaps some sort of [controversial] marker would be useful to warn > > people that the item needs more discussion before going off in a corner > > and trying to implement it. > > > > regards, tom lane > > > > Actually some items are marked with a '?' that shows that that item > needs discussion... although that it's not clearly stated in no where > in the TODO... > > Maybe be explicit about what the '?' mark means and mark every new > item with it until there is concensus a on it Well, I would think a question mark would be pretty clear. The problem here is that no one objected to its addition to the TODO list, so it never got a "?". -- 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
On Sat, 2005-12-10 at 21:16 -0500, Bruce Momjian wrote: > Not sure what else can be done to improve this process. I think the barrier to adding new TODO entries or modifying existing ones is too high. While it's great that Bruce maintains the list, the inevitable result is that the list tends to reflect the discussions and features that the TODO list maintainer thinks are interesting. Why is the TODO list keep in the source code repository, anyway? One alternative would be to move it to a wiki. That would allow other people to contribute to maintaining the list, with less procedural overhead. The GCC folks do this, for example: example: http://gcc.gnu.org/wiki/ > And our developer TODO has: [...] > So I think we are covered there too. I don't see that we're "covered": sure, it's documented that people ought to ask on -hackers first, but this exact situation has happened several times in the past. Avoiding that would be a good thing, documentation or no. -Neil
Bruce Momjian wrote: > Well, the item was added at the request of Peter Eisentraut and > Martijn van Oosterhout and took place on hackers. The TODO addition > was posted too: > http://archives.postgresql.org/pgsql-hackers/2005-12/msg00333.php The discussion did not mention anything about running a script on normal shutdown. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Neil Conway <neilc@samurai.com> writes:
> On Sat, 2005-12-10 at 21:16 -0500, Bruce Momjian wrote:
>> Not sure what else can be done to improve this process.
> Why is the TODO list keep in the source code repository, anyway? One
> alternative would be to move it to a wiki.
That seems unlikely to improve the quality of the list :-(. With the
present process, entries are made after some discussion on the mailing
list, and at least most of the time there's some consensus that an idea
is good. With a wiki, anyone could stick an item on there with no peer
review. The only way you get any review is if people watch the wiki
as carefully as they watch the mailing lists ... and I for one don't
need any additional time sinks.
The real problem that I see is that Bruce abstracts the discussions
down into one-line summaries that frequently omit critical information.
I would like to see all the TODO items include links to the archived
threads that led up to them. In this example, had the patch author gone
back and looked at the thread, he'd have noticed that at no point was
there a discussion of running scripts during database shutdown.
regards, tom lane
On Sun, 2005-12-11 at 11:55 -0500, Tom Lane wrote: > That seems unlikely to improve the quality of the list :-(. With the > present process, entries are made after some discussion on the mailing > list, and at least most of the time there's some consensus that an idea > is good. With a wiki, anyone could stick an item on there with no peer > review. In practice, I really doubt that people are going to spend their time adding suboptimal entries to the TODO list. If the document is regularly read and edited by multiple developers (as would be the case if it was used at all), I think the clearly bad ideas would be rooted out quickly, and the "not terrible but not clearly worthwhile" ideas would have the necessary caveats. > The real problem that I see is that Bruce abstracts the discussions > down into one-line summaries that frequently omit critical information. I agree, but I think this is another symptom of having only one person maintain the list. It is a non-trivial amount of work to understand all the arguments in a complex -hackers thread and distill that into a few accurate sentences that summarize the consensus (if there even was one!). I'm not at all surprised when the TODO entry that results is incomplete or misleading if the person doing the summary wasn't one of the primary participants in the -hackers thread. Short of going to a wiki, I think we can at least make it easier for other committers to modify the TODO list. What format is doc/TODO in, anyway? (It doesn't seem to be normal plaintext.) Why is there also an HTML copy of the TODO list (doc/src/FAQ/TODO.html) kept in CVS? (I'd rather we not keep generated files in CVS, in general.) I think a concrete improvement would be to get rid of all that, and maintain a master copy of the TODO list in some sane format -- or failing that, DocBook :) -Neil
> Why is the TODO list keep in the source code repository, anyway? One > alternative would be to move it to a wiki. That would allow other people > to contribute to maintaining the list, with less procedural overhead. > The GCC folks do this, for example: example: http://gcc.gnu.org/wiki/ I agree with this. It would add visibility to what the direction of PostgreSQL as well as put a friendly face on what the heck is happening. I get a lot of calls that are basically, "What's coming in 8.2" Unless I follow the lists it is not an easy bit of information to get. A wiki that had a page that said, "What's planned for 8.2!" or would be great! It would also be useful to see who has signed on as the lead or to work on a particular subproject in case other developers would like to either lead or help a lead on the project. I would request a vote interface but I think we would get to many mysqlisms ;) > I don't see that we're "covered": sure, it's documented that people > ought to ask on -hackers first, but this exact situation has happened > several times in the past. Avoiding that would be a good thing, > documentation or no. Agreed. Joshua D. Drake > > -Neil > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > -- Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564 Custom programming, 24x7 support, managed services, and hosting Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG Reliable replication, Mammoth Replicator - http://www.commandprompt.com/
Tom Lane wrote: > > The real problem that I see is that Bruce abstracts the discussions > down into one-line summaries that frequently omit critical information. > I would like to see all the TODO items include links to the archived > threads that led up to them. I think that would be the single most effective change to make (thinking back to last two TODOs that I tackled - it was quite difficult to find the mail thread(s) containing the details). regards Mark
> Short of going to a wiki, I think we can at least make it easier for > other committers to modify the TODO list. What format is doc/TODO in, > anyway? (It doesn't seem to be normal plaintext.) Why is there also an > HTML copy of the TODO list (doc/src/FAQ/TODO.html) kept in CVS? (I'd > rather we not keep generated files in CVS, in general.) > > I think a concrete improvement would be to get rid of all that, and > maintain a master copy of the TODO list in some sane format -- or > failing that, DocBook :) Call me crazy - but isn't this what you usually use a bug tracker for? Chris
On Mon, 2005-12-12 at 09:39 +0800, Christopher Kings-Lynne wrote: > Call me crazy - but isn't this what you usually use a bug tracker for? Well, some people do. I don't really see the point, though. What advantages would it have? -Neil
Neil Conway wrote: > I don't see that we're "covered": sure, it's documented that people > ought to ask on -hackers first, but this exact situation has happened > several times in the past. Avoiding that would be a good thing, > documentation or no. If you want to change the system we use for the TODO list, don't do it because our current system has failed on occasion. Do it because you think the new system will fail less often. Any system we choose will fail at times. -- 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
Neil Conway wrote: > On Sat, 2005-12-10 at 21:16 -0500, Bruce Momjian wrote: > > Not sure what else can be done to improve this process. > > I think the barrier to adding new TODO entries or modifying existing > ones is too high. While it's great that Bruce maintains the list, the > inevitable result is that the list tends to reflect the discussions and > features that the TODO list maintainer thinks are interesting. I really try not to interject my opinion into the TODO entry, though I did in this case to try and make it more general, and messed it up. Is there any valid TODO here? I could put the URL in the TODO entry but it would be pretty ugly and often the email thread rambles all over, so my summary is more a summary of the conclusions. I would like other developers to add/modify the todo list. The master is the text file, and I generate the HTML so the web team can pull the HTML for our web site. If you modify just the text file, I will see the commit and update the HTML, and if you want my scripts, I can send them out. Also, if I post the summary of the TODO added (to the list and the committers list), please comment if the item can be improved. I get very little feedback on items I add, and I am not sure why. A wiki seems like a change for the worse because instead of having a few incorrect entries, we will have tons. -- 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
Neil Conway wrote: > I agree, but I think this is another symptom of having only one person > maintain the list. It is a non-trivial amount of work to understand all > the arguments in a complex -hackers thread and distill that into a few > accurate sentences that summarize the consensus (if there even was > one!). I'm not at all surprised when the TODO entry that results is > incomplete or misleading if the person doing the summary wasn't one of > the primary participants in the -hackers thread. Why can't others modify the TODO list, or FAQ for that matter. I get patches for the later, but few for the former. > > Short of going to a wiki, I think we can at least make it easier for > other committers to modify the TODO list. What format is doc/TODO in, > anyway? (It doesn't seem to be normal plaintext.) Why is there also an > HTML copy of the TODO list (doc/src/FAQ/TODO.html) kept in CVS? (I'd > rather we not keep generated files in CVS, in general.) > > I think a concrete improvement would be to get rid of all that, and > maintain a master copy of the TODO list in some sane format -- or > failing that, DocBook :) I replied to this in another email. -- 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
Joshua D. Drake wrote: > > Why is the TODO list keep in the source code repository, anyway? One > > alternative would be to move it to a wiki. That would allow other people > > to contribute to maintaining the list, with less procedural overhead. > > The GCC folks do this, for example: example: http://gcc.gnu.org/wiki/ > > I agree with this. It would add visibility to what the direction of > PostgreSQL as well as put a friendly face on what the heck is > happening. > > I get a lot of calls that are basically, "What's coming in 8.2" Unless I > follow the lists it is not an easy bit of information to get. A wiki that had > a page that said, "What's planned for 8.2!" or would be great! > > It would also be useful to see who has signed on as the lead or to work on > a particular subproject in case other developers would like to either lead > or help a lead on the project. > > I would request a vote interface but I think we would get to many > mysqlisms ;) You are dreaming on this one. Of our changes in any major release, probably 40% are from the TODO list, and 60% are just patches submitted. How does aomething even get on the TODO list from a patch? To do what you want requires someone with technical knowlege to spend serious time analyzing the CVS commits and digesting it into a web page. I can be done, but it isn't the same purpose as the TODO list. -- 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
>> It would also be useful to see who has signed on as the lead or to work on >> a particular subproject in case other developers would like to either lead >> or help a lead on the project. >> >> I would request a vote interface but I think we would get to many >> mysqlisms ;) > > You are dreaming on this one. Man then all those other FOSS projects like (KDE/Mozilla) that do it must be sleeping through the whole development cycle. > Of our changes in any major release, > probably 40% are from the TODO list, and 60% are just patches submitted. > How does aomething even get on the TODO list from a patch? A bug/request tracker? > To do what you want requires someone with technical knowlege to spend > serious time analyzing the CVS commits and digesting it into a web page. Not if the infrastructure is put in place to deal with it in the first place. If a patch is accepted, when it is accepted a simple message that says: Accepted for 8.2 + Adds capability to program VCR Pretty much does everything we need. > I can be done, but it isn't the same purpose as the TODO list. Actually it is. It is called overall project management and it is something that has come up here many times. I guess I just don't understand why so many other projects larger then us and much smaller then us can do it, but we can't. Here are some examples of some projects that have actual stated goals that are OSS: KDE Gnome Trac Django Firebird Python We do, provide some feedback to what is going on from the website but the barrier is pretty high in comparison to these other websites. Not to mention how hard it is to figure out what bugs have been patched or haven't. Sincerely, Joshua D. Drake > > -- Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564 Custom programming, 24x7 support, managed services, and hosting Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG Reliable replication, Mammoth Replicator - http://www.commandprompt.com/
Joshua D. Drake wrote: > >> It would also be useful to see who has signed on as the lead or to work on > >> a particular subproject in case other developers would like to either lead > >> or help a lead on the project. > >> > >> I would request a vote interface but I think we would get to many > >> mysqlisms ;) > > > > You are dreaming on this one. > > Man then all those other FOSS projects like (KDE/Mozilla) that do it must > be sleeping through the whole development cycle. I doubt you want to put Mozilla up as a better managed project than us. And the Mozilla roadmap was a joke, and probably helped them fail while more nimble Firefox took over. > > Of our changes in any major release, > > probably 40% are from the TODO list, and 60% are just patches submitted. > > How does something even get on the TODO list from a patch? > > A bug/request tracker? We have discussed that. You want tracking or work accomplished? Pick one. Ideally we could do both, but we have finite resources. I am sure something like Open Office or one of those big company-funded projects can do this, but the bureaucracy has its own disadvantages, and I doubt most of us would accept them. > > To do what you want requires someone with technical knowledge to spend > > serious time analyzing the CVS commits and digesting it into a web page. > > Not if the infrastructure is put in place to deal with it in the first > place. > > If a patch is accepted, when it is accepted a simple message that says: > > Accepted for 8.2 + Adds capability to program VCR We have that in the CVS logs. Why don't _you_ track the commits and keep a web site up to date, or someone else? That's all it takes --- take the CVS commits, merge them and summarize them on a web site. Why has no one done that yet if it is so needed? > Pretty much does everything we need. Go ahead. No one is stopping someone from doing that? Do they need help from the project to do that? No. > > I can be done, but it isn't the same purpose as the TODO list. > > Actually it is. It is called overall project management and it is > something that has come up here many times. > > I guess I just don't understand why so many other projects larger then us > and much smaller then us can do it, but we can't. > > Here are some examples of some projects that have actual stated goals that > are OSS: > > KDE > Gnome > Trac > Django > Firebird > Python Please show me an actual example, not a project list. I picked Trac at random and looked at their web site. The Timeline is a list of message that all say Sandbox or Ticket. I don't see how that helps more than our CVS logs. I looked at roadmap and it had a few bullet points but was to small/general. Our TODO list blows it away in detail and size. > We do, provide some feedback to what is going on from the web site but the > barrier is pretty high in comparison to these other web sites. Not to > mention how hard it is to figure out what bugs have been patched or > haven't. Agreed. We need someone to maintain that. Who wants to do it? It only requires HTML skills, which I think enough people in this project already have. Basically, there are two things to track --- what will/might happen (TODO), and what has happened (CVS). Right now CVS only becomes visible when a release happens, and the release notes themselves are abridged, meaning they don't mention every fix, like fixing the --help argument display for a command or something. The TODO does a pretty good job of what will/might happen, but we could use more work on the pending (not released yet) changes in CVS, and a release note listing that is more detailed than what we have now. I myself am not interested in expending time in these areas as I am already busy with my current responsibilities, and I think I am spending my time in the most fruitful way by concentrating on what I do now. If I am wrong, please someone tell me why I am wrong. Don't way we would like to have X too as well as what we already have, but not supply any more manpower. You might as well say you want to live forever, but not give any way of accomplishing it. -- 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
Joshua D. Drake wrote: > I guess I just don't understand why so many other projects larger > then us and much smaller then us can do it, but we can't. Perhaps it is a question of project culture. As I see PostgreSQL development, there is no such thing as a roadmap or an agreed plan, what "the group" will implement feature-wise. (Of course everyone agrees that we should improve performance, support new SQL standard features, etc... that is not my point). I believe it is pretty much each individual's (or backing company's) decision, what features they will hack on. If there is interest in a feature from more than one person, sometimes they will work together in groups on that part. But I don't see anyone making lists of features that should be in version X and then say: "Let's get this list of work done!". (Btw. I think this is a strengh of PostgreSQL, not a weakness.) As Bruce said, if you want to tell what will be in the next release, you can only look at CVS commits and discussions. The projects of some people are more likely to be in the next release than others, but who knows before the patches are committed. What I would find good for marketing is a list of features that should be in the next release (after they have been committed to CVS). Nevertheless this is not a trivial task. IIRC Bruce did regular updates to the release notes during the development cycle of a release or two ago. He gave it up because it cost too much time. Perhaps someone else wants to step up to maintain such a list, not as detailed as the release notes probably. Just my two (Euro)cents. Best Regards, Michael Paesold
Bruce Momjian wrote: > I would like other developers to add/modify the todo list. The > master is the text file, and I generate the HTML so the web team can > pull the HTML for our web site. If you modify just the text file, I > will see the commit and update the HTML, and if you want my scripts, > I can send them out. I suggest that the non-master copies of the TODO and the FAQ be removed from CVS. Moreover, replace the README by a Makefile, and have the web team and/or the release bundling script run the commands required for their purpose. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Sun, 2005-12-11 at 23:54 -0500, Bruce Momjian wrote: > If I am wrong, please someone tell me why I am wrong. Don't way we > would like to have X too as well as what we already have, but not supply > any more manpower. You might as well say you want to live forever, but > not give any way of accomplishing it. I am very impressed with the way things run around here. I've observed at close hand, but externally to, one RDBMS dev organisation and the problems we have are like nothing in comparison. I've also sat on various company architecture boards and PostgreSQL would be rated within the top quartile of those. Keeping things open makes the whole process less impersonal and better decisions are made as a result. Keeping things flexible is important too and we could easily lose that for no gain. Bruce has expanded the TODO list and does that very even-handedly. A bugtracker would not make that happen any better, probably worse. There is one area where we are lacking and that is having an organised programme for helping and encouraging new developers. My fairly broad-brush gut feel would be that about 50% of new developers fall foul of the process somehow and never finish their patches as a result. I don't believe this thread is an isolated example. In the short term we could justify that based solely on the time savings for major developers, though in the long term this could pay off handsomely for everybody. Regular "Developer Training" by phone, please. Caller pays their own costs. Something like WebEx... Best Regards, Simon Riggs
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > I would like other developers to add/modify the todo list. The
> > master is the text file, and I generate the HTML so the web team can
> > pull the HTML for our web site. If you modify just the text file, I
> > will see the commit and update the HTML, and if you want my scripts,
> > I can send them out.
>
> I suggest that the non-master copies of the TODO and the FAQ be removed
> from CVS. Moreover, replace the README by a Makefile, and have the web
> team and/or the release bundling script run the commands required for
> their purpose.
Sure, I can supply the scripts. I put them on FTP as put*:
ftp://candle.pha.pa.us/pub/postgresql/mypatches
There are ones for TODO, FAQ, and FAQ_DEV. The only non-standard
program needed is txt2html from:
http://txt2html.sourceforge.net/
I only generated the HTML for TODO to make it easy for the web guys to
pull it, and seeing that tools seem to come and go on the PostgreSQL
servers (as they did for a recent upgrade) I considered it safer to do
it all on my end.
Feel free to put things in place and I will CVS remove the HTML version
of TODO. The FAQ's are already in HTML format as the master, and if
Marc wants to put something in place for packaging that builds the text
versions, I can remove the text versions of those too.
--
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