Re: [DOCS] [HACKERS] Uniform policy for author credits in contrib module documentation?
Tom Lane wrote: Josh Berkus <[EMAIL PROTECTED]> writes: Historically, the only way to troubleshoot some of the contrib modules was to e-mail the author. If people think that we've reached a standard that everything in /contrib is now well-documented and supported by the general community, the I suppose we don't need contact information. I'm not so sure myself. I do not think that we should encourage people to mail the authors first rather than pgsql-bugs. For one thing, a lot of those addresses are dead, and some of the ones that aren't don't respond especially fast. If the community-at-large can't handle a bug, we certainly have enough institutional memory to try to contact the original author, even if that address isn't in the SGML docs. Perhaps the at a minimum the email goes in the commit? Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] [HACKERS] Uniform policy for author credits in contrib module documentation?
On Dec 7, 2007 9:03 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > > Joshua D. Drake wrote: > > Tom Lane wrote: > >> Josh Berkus <[EMAIL PROTECTED]> writes: > >>> Historically, the only way to troubleshoot some of the contrib > >>> modules was to e-mail the author. If people think that we've > >>> reached a standard that everything in /contrib is now > >>> well-documented and supported by the general community, the I > >>> suppose we don't need contact information. I'm not so sure myself. > >> > >> I do not think that we should encourage people to mail the authors first > >> rather than pgsql-bugs. For one thing, a lot of those addresses are > >> dead, and some of the ones that aren't don't respond especially fast. > >> > >> If the community-at-large can't handle a bug, we certainly have enough > >> institutional memory to try to contact the original author, even if that > >> address isn't in the SGML docs. > >> > > > > Perhaps the at a minimum the email goes in the commit? > > > > I don't see any reason, unless we're going to start doing that for all > contributions. 'contrib' is a serious misnomer anyway, and there's no > reason to think in general that the original author is specially > responsible for any of it. I think Tom's point is entirely valid. I think it is totally appropriate to replace the email address contact information with a link to pgsql-bugs. But there are reasons other than bugfixing to contact the original author of a patch or contrib packages. Some of those could include: * collaboration on a professional, hobby or academic research level * journalism/books written about PostgreSQL * academic or historical research into the development of PostgreSQL * job prospects * socializing For those reasons, I think it would be a huge loss to the community to remove the credit sections or to prevent their inclusion in future documentation. Maintaining them leaves a breadcrumb trail that otherwise would be lost in mailing list threads and commit logs that are very difficult for a person without specialized knowledge to navigate. Why make contacting people hard? Some of the contrib features are likely targets for future research and development (for example: tsearch, HOT, pl/lolcode - not contrib, but awesome!) and in that context, the specific people involved are important. Contrib documentation will get folded into the main docs eventually (and at that point, the credits are removed). But the record of that evolution is easily accessed, without any special knowledge of a revision control system, or mailing list culture. And I realize that the logical extension of what I am saying is a research and documentation project about the people who all have contributed to the development of PostgreSQL. -selena -- Selena Deckelmann PDXPUG - Portland PostgreSQL Users Group http://pugs.postgresql.org/pdx http://www.chesnok.com/daily ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [DOCS] "distributed checkpoint"
On Thu, 2007-12-06 at 19:43 -0800, David Fetter wrote: > On Thu, Dec 06, 2007 at 07:19:44PM -0800, Joshua D. Drake wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Thu, 06 Dec 2007 20:44:49 -0500 > > Tom Lane <[EMAIL PROTECTED]> wrote: > > > > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > > Am I the only one who finds the phrase "distributed checkpointing" > > > > a bit awkward? Would it be better if we used "time-distributed > > > > checkpointing" instead? > > > > > > Yeah, "distributed" has a bunch of connotations that are wrong for > > > this purpose. > > > > > > I spent a bit of time with a thesaurus but didn't come up with > > > anything that seemed le mot juste. Best I could do was "spread > > > checkpoint" or "time-extended checkpoint". Anybody have a better > > > idea? > > > > balanced > > gradual > > extended (I see you mention time-extended but wouldn't time be implicit > > based on the actual docs and thus we only need extended?) > > How about "smoothed?" Agreed "Smoothed" makes a lot of sense for me. We used to have a checkpoint spike, now we don't. Perhaps we should say something like "time extended checkpoints provide smoother (transaction?) response times" -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [DOCS] "distributed checkpoint"
On Fri, 7 Dec 2007, Simon Riggs wrote: "Smoothed" makes a lot of sense for me. We used to have a checkpoint spike, now we don't. To be accurate, there used to be a huge and unavoidable spike, now there's a control that aims to make it smaller. The problem hasn't completely gone away yet. With that in mind, let me start over. Here's what's in the release notes right now: "Distributed checkpoints prevent I/O spikes during checkpoints" It's good this came up, because that is factually wrong; while the average case is much better some OS-dependant aspects of the spike (what happens at fsync) are certainly still there. I think it's easier to rewrite this whole thing so it's technically accurate rather than a simple fix of the wording, something like this: "Checkpoint writes can be spread over a longer time period to smooth the I/O spike during each checkpoint" It's got spread, it's got smooth, and if I could have worked "silky" in there too I would have. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] [HACKERS] Uniform policy for author credits in contrib module documentation?
Joshua D. Drake wrote: Tom Lane wrote: Josh Berkus <[EMAIL PROTECTED]> writes: Historically, the only way to troubleshoot some of the contrib modules was to e-mail the author. If people think that we've reached a standard that everything in /contrib is now well-documented and supported by the general community, the I suppose we don't need contact information. I'm not so sure myself. I do not think that we should encourage people to mail the authors first rather than pgsql-bugs. For one thing, a lot of those addresses are dead, and some of the ones that aren't don't respond especially fast. If the community-at-large can't handle a bug, we certainly have enough institutional memory to try to contact the original author, even if that address isn't in the SGML docs. Perhaps the at a minimum the email goes in the commit? I don't see any reason, unless we're going to start doing that for all contributions. 'contrib' is a serious misnomer anyway, and there's no reason to think in general that the original author is specially responsible for any of it. I think Tom's point is entirely valid. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
