Re: [DOCS] [GENERAL] [pgsql-advocacy] Documentation quality WAS: interesting
> Agreed. I am starting a list of what can/need to be indexed on pgsql docs > site as I'm working to build a new site with pgsql as a backend. I > think Tom Lane > suggested that.. I would like to know where I can send > the list. It'll probably somekind of a work in progress. So if everyone > else can contribute, > it'll be so much faster. Probably a semi-automated > system for handling those > lists? Assuming some kind of full-text search facility, an interesting idea would be a self-updating index, one that keeps track of what search terms are commonly used and adds those to the index automatically. -- Mike Nolan ---(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
[DOCS] Is someone actively working on the binary replication tutorial wiki page?
I've been trying to set up binary replication in 9.1.3 on two test servers using the instructions in the wiki binary replication tutorial. I did get it working last night ,but ran into some issues that aren't covered, such as what to do with a database that has multiple tablespaces. This wiki page does not seem to have been updated since early 2011. Is anyone working on that page these days? How do I get involved helping update it? -- Mike Nolan
Re: [DOCS] Is someone actively working on the binary replication tutorial wiki page?
On Fri, Mar 30, 2012 at 12:45 PM, Heikki Linnakangas < [email protected]> wrote: > How do I get involved helping update it? >> > > > Just login and start editing. If you don't have a community account yet, > you'll need to create one first, but that won't take long ( > https://www.postgresql.org/**account/signup/<https://www.postgresql.org/account/signup/> > ) > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > Got it, thanks. I've made one (minor) edit so far, just to gain some familiarity with the process. -- Mike Nolan
[DOCS] Fwd: [GENERAL] 9.1.3: launching streaming replication
-- Forwarded message -- From: Welty, Richard Date: Tue, Apr 3, 2012 at 5:33 PM Subject: RE: [GENERAL] 9.1.3: launching streaming replication To: Michael Nolan ** >you may want to do something with the other, then, as it's what came up when i went searching >for help. to amplify, the other page comes up first in a google search for "postgresql streaming replication" which is how i found it. richard Not sure how I found the other page first, but I'll look at that page, it looks like it hasn't been updated for 9.1 yet, either. It also doesn't show up in the topic category page for replication. http://wiki.postgresql.org/wiki/Category:Replication I don't how to update that one (or if that's left up to the administrators), so I'm sending this note on to the pgsql-docs list as well. -- Mike Nolan
Re: [DOCS] Fwd: [GENERAL] 9.1.3: launching streaming replication
On Tue, Apr 3, 2012 at 7:30 PM, Greg Smith wrote: > Mike already fixed the category problem himself. I just updated > http://wiki.postgresql.org/wiki/Streaming_Replication so that it suggests > users visit the official docs and tutorial on the wiki, since we can't just > make Google unlike that page easily. > Greg, there's sort of an inconsistency between the developer-oriented streaming replication page and the tutorial. The streaming replication page says to copy the entire data directory, which would include the WAL logs in the pg_xlog directory. The 5 minute version in the binary replication tutorial skips that directory, the longer one copies it separately, after the backup is complete, so that the slave can perform any committed changes as part of syncing up with the master. I assume that there is no harm in copying the pg_xlog directory in the 5 minute version, and it was left out as a time-saver. However, if the master fails and the slave has to take over, wouldn't it need the pg_xlog directory? If it hasn't been created, could that cause problems or would the backend know to create it? -- Mike Nolan
Re: [DOCS] A user report of misinterpretation of `unsupported versions`
On Fri, Jul 12, 2013 at 9:01 PM, Greg Sabino Mullane wrote: > > > How about we simply list all versions, without classifying them as > unsupported or not? > Is there an automated mechanism by which a version would move from the 'supported' group to the 'unsupported' group, eg, when 8.4 goes EOL? Perhaps it would be more clear to first identify what version this page covers, then provide the equivalent links to other versions, such as: This page is for PostgreSQL version 9.2 For the equivalent page in other versions see: Currently Supported Versions: 9.1, 9.0, 8.4 Unreleased or Development versions: 9.3, Devel Older releases that are no longer being maintained: 8.3, 8.2, 8.1, 8.0 -- Mike Nolan
Re: [DOCS] A user report of misinterpretation of 'unsupported versions'
On Sun, Jul 14, 2013 at 11:22 AM, Tom Lane wrote: > > > In any case, if we do change the wording, I'd like to lobby again > for using "obsolete" rather than "unsupported" for EOL versions. > That seems less likely to be misinterpreted. > I suggested the following wording: This page is for PostgreSQL version 9.2 For the equivalent page in other versions see: Currently Supported Versions: 9.1, 9.0, 8.4 Unreleased or Development versions: 9.3, Devel Older releases that are no longer being maintained: 8.3, 8.2, 8.1, 8.0 Yes, it is more verbose, but the web is one place where space is not at a premium, and this is (IMHO) far clearer for the casual reader. A separate issue is, when 9.3 goes live or 8.4 goes EOL, do these pages automatically get moved to the 'supported' or 'not maintained' sections, respectively, or do all these pages have to be revised? -- Mike Nolan
Re: [DOCS] A user report of misinterpretation of 'unsupported versions'
On Mon, Jul 15, 2013 at 4:52 AM, Magnus Hagander wrote: > On Sun, Jul 14, 2013 at 5:42 PM, Michael Nolan wrote: > > > > > > On Sun, Jul 14, 2013 at 11:22 AM, Tom Lane wrote: > >> > >> > >> > >> In any case, if we do change the wording, I'd like to lobby again > >> for using "obsolete" rather than "unsupported" for EOL versions. > >> That seems less likely to be misinterpreted. > > > > > > I suggested the following wording: > > > > This page is for PostgreSQL version 9.2 > > For the equivalent page in other versions see: > > Currently Supported Versions: 9.1, 9.0, 8.4 > > Unreleased or Development versions: 9.3, Devel > > Older releases that are no longer being maintained: 8.3, 8.2, 8.1, 8.0 > > > > Yes, it is more verbose, but the web is one place where space is not at a > > premium, and this is (IMHO) far clearer for the casual reader. > > Actually, space "above the fold" *is* at a huge premium on the web. > True, but 'how do I get to this page for some other version?' isn't the reason someone brings up a page, so it doesn't need to be above the fold. Prime space should be used for prime purposes. > > If we put it at the bottom of the page your argument for space not at > a premium would be valid. But we really don't want anything using up > more than one row at the top. > Why do we need anything at all at the top regarding other versions? It is probably desirable to say what version a page is for as part of the overall description of what the page is about, and that can probably fit on one line. > > > A separate issue is, when 9.3 goes live or 8.4 goes EOL, do these pages > > automatically get moved to the 'supported' or 'not maintained' sections, > > respectively, or do all these pages have to be revised? > > That is all handled automatically. > I suspected as much, but what happens behind the curtain is not always obvious (nor does it need to be for 99% of the user community.) Thanks for enlightening me. -- Mike Nolan > >
