running script on server shutdown (TODO)

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/