Thread: Londiste
Can anyone suggest where a "Londiste" mention would fit in our high
availability docs?
http://developer.postgresql.org/pgdocs/postgres/high-availability.html
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
Bruce Momjian writes: > Can anyone suggest where a "Londiste" mention would fit in our high > availability docs? I would suggest a new category. 25.1 (Comparison of different solutions) lists this one type of solution "Trigger-Based Master-Slave Replication". Perhaps a category for Trigger-Based Master-Slave Replication coulde be 25.7. This would work not only for Londiste but for anything else that uses triggers.
On Mon, May 24, 2010 at 7:52 PM, Bruce Momjian <bruce@momjian.us> wrote: > Can anyone suggest where a "Londiste" mention would fit in our high > availability docs? > > http://developer.postgresql.org/pgdocs/postgres/high-availability.html I would think wherever we mention Slony - I gather that they are fairly similar in implementation, though I might be wrong about that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas writes: > On Mon, May 24, 2010 at 7:52 PM, Bruce Momjian <bruce@momjian.us> wrote: >> Can anyone suggest where a "Londiste" mention would fit in our high >> availability docs? >> >> http://developer.postgresql.org/pgdocs/postgres/high-availability.html > > I would think wherever we mention Slony - I gather that they are > fairly similar in implementation, though I might be wrong about that. I thought the same, however I did not see Slony mentioned on that URL. At least it was not in an obvious place.
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > Can anyone suggest where a "Londiste" mention would fit in our high > availability docs? > > http://developer.postgresql.org/pgdocs/postgres/high-availability.html We already have Slony there as an "example of" async master-slave. Is there some problem you are trying to fix? It would be hard to add this without opening the floodgates of mentioning all replication systems. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201005251122 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkv761kACgkQvJuQZxSWSsjYFQCffN4mhOf+9+4bwmMeQxkJRHu2 4fIAoJpFw3u3r8e2cSd5fM5WyfHWnBGZ =I+Gg -----END PGP SIGNATURE-----
Greg Sabino Mullane wrote: [ There is text before PGP section. ] > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > > Can anyone suggest where a "Londiste" mention would fit in our high > > availability docs? > > > > http://developer.postgresql.org/pgdocs/postgres/high-availability.html > > We already have Slony there as an "example of" async master-slave. Is > there some problem you are trying to fix? It would be hard to add this > without opening the floodgates of mentioning all replication systems. Well, I assumed "Londiste" head reached the level that we should mention it, but you are right on the floodgates issue. We do aleady mention many other replication solutions in other sections, so I didn't think the flood would be too bad. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
Bruce Momjian writes: > Well, I assumed "Londiste" head reached the level that we should mention > it, but you are right on the floodgates issue. We do aleady mention > many other replication solutions in other sections, so I didn't think Then perhaps all that is needed is to just link to the replication section of the wiki: http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool ing A search for replication on the top of the doc page (ie http://www.postgresql.org/docs/8.4/interactive/index.html) takes to the high availability page, so a reference there to the wiki page may be a good idea.
Francisco Reyes wrote: > Bruce Momjian writes: > > > Well, I assumed "Londiste" head reached the level that we should mention > > it, but you are right on the floodgates issue. We do aleady mention > > many other replication solutions in other sections, so I didn't think > > Then perhaps all that is needed is to just link to the replication section > of the wiki: > http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool > ing > > A search for replication on the top of the doc page (ie > http://www.postgresql.org/docs/8.4/interactive/index.html) takes to the high > availability page, so a reference there to the wiki page may be a good idea. That is an excellent idea, not only for replication, but there are probably other wiki pages that we should link to from our main docs. I will go through the wiki, find appropriate pages, and add links from our docs. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
On Tue, 2010-05-25 at 15:23 +0000, Greg Sabino Mullane wrote: > > Can anyone suggest where a "Londiste" mention would fit in our high > > availability docs? > > > > http://developer.postgresql.org/pgdocs/postgres/high-availability.html > > We already have Slony there as an "example of" async master-slave. Is > there some problem you are trying to fix? It would be hard to add this > without opening the floodgates of mentioning all replication systems. Don't see a problem with mentioning Londiste. It's not like there's that many production-strength candidates that we shouldn't mention them all. Right now, I see it as the only missing one on the list. BTW Bruce, "log shipping" isn't mentioned at all in that section, which is strange since that's what's in 9.0. -- Simon Riggs www.2ndQuadrant.com
On Tue, May 25, 2010 at 2:15 PM, Bruce Momjian <bruce@momjian.us> wrote: > Francisco Reyes wrote: >> Bruce Momjian writes: >> >> > Well, I assumed "Londiste" head reached the level that we should mention >> > it, but you are right on the floodgates issue. We do aleady mention >> > many other replication solutions in other sections, so I didn't think >> >> Then perhaps all that is needed is to just link to the replication section >> of the wiki: >> http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool >> ing >> >> A search for replication on the top of the doc page (ie >> http://www.postgresql.org/docs/8.4/interactive/index.html) takes to the high >> availability page, so a reference there to the wiki page may be a good idea. > > That is an excellent idea, not only for replication, but there are > probably other wiki pages that we should link to from our main docs. I > will go through the wiki, find appropriate pages, and add links from our > docs. I don't know that I'm eager to link from our docs to the wiki. That seems likely to lead to maintenance headaches. But on the other hand, I see no problem mentioning third-party products that are part of the PG ecosystem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Excerpts from Robert Haas's message of mié may 26 15:56:45 -0400 2010: > > That is an excellent idea, not only for replication, but there are > > probably other wiki pages that we should link to from our main docs. I > > will go through the wiki, find appropriate pages, and add links from our > > docs. > > I don't know that I'm eager to link from our docs to the wiki. That > seems likely to lead to maintenance headaches. But on the other hand, > I see no problem mentioning third-party products that are part of the > PG ecosystem. I don't think we should be adding hundreds of wiki links to the docs, but if it's just half a dozen, I think it's a good idea. Those pages have already undergone a lot of revision and they are unlikely to go away. We already have links to pages in external sites and they do cause some pain, but it's not much and this is only every two years or so. Keep in mind that pages in the Wiki are going to be replaced by a redirect page if they ever get renamed, for example. It's highly unlikely that they are going to disappear completely. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Robert Haas wrote: > On Tue, May 25, 2010 at 2:15 PM, Bruce Momjian <bruce@momjian.us> wrote: > > Francisco Reyes wrote: > >> Bruce Momjian writes: > >> > >> > Well, I assumed "Londiste" head reached the level that we should mention > >> > it, but you are right on the floodgates issue. ?We do aleady mention > >> > many other replication solutions in other sections, so I didn't think > >> > >> Then perhaps all that is needed is to just link to the replication section > >> of the wiki: > >> http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool > >> ing > >> > >> A search for replication on the top of the doc page (ie > >> http://www.postgresql.org/docs/8.4/interactive/index.html) takes to the high > >> availability page, so a reference there to the wiki page may be a good idea. > > > > That is an excellent idea, not only for replication, but there are > > probably other wiki pages that we should link to from our main docs. ?I > > will go through the wiki, find appropriate pages, and add links from our > > docs. > > I don't know that I'm eager to link from our docs to the wiki. That > seems likely to lead to maintenance headaches. But on the other hand, > I see no problem mentioning third-party products that are part of the > PG ecosystem. Well, the problem is that we have more solutions that fit in the docs in normal places. I was thinking of just linking to major wiki pages, like replication and pooling. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
On Wed, May 26, 2010 at 4:03 PM, alvherre <alvherre@commandprompt.com> wrote: > Excerpts from Robert Haas's message of mié may 26 15:56:45 -0400 2010: > >> > That is an excellent idea, not only for replication, but there are >> > probably other wiki pages that we should link to from our main docs. I >> > will go through the wiki, find appropriate pages, and add links from our >> > docs. >> >> I don't know that I'm eager to link from our docs to the wiki. That >> seems likely to lead to maintenance headaches. But on the other hand, >> I see no problem mentioning third-party products that are part of the >> PG ecosystem. > > I don't think we should be adding hundreds of wiki links to the docs, > but if it's just half a dozen, I think it's a good idea. Those pages > have already undergone a lot of revision and they are unlikely to go > away. We already have links to pages in external sites and they do > cause some pain, but it's not much and this is only every two years or so. > > Keep in mind that pages in the Wiki are going to be replaced by a > redirect page if they ever get renamed, for example. It's highly > unlikely that they are going to disappear completely. Eh, maybe. I think generally the wiki documentation is of lower quality than our main docs. I'd rather see us put the effort into writing something that can be incorporated into the docs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Wed, May 26, 2010 at 5:45 PM, Bruce Momjian <bruce@momjian.us> wrote: > Robert Haas wrote: >> On Tue, May 25, 2010 at 2:15 PM, Bruce Momjian <bruce@momjian.us> wrote: >> > Francisco Reyes wrote: >> >> Bruce Momjian writes: >> >> >> >> > Well, I assumed "Londiste" head reached the level that we should mention >> >> > it, but you are right on the floodgates issue. ?We do aleady mention >> >> > many other replication solutions in other sections, so I didn't think >> >> >> >> Then perhaps all that is needed is to just link to the replication section >> >> of the wiki: >> >> http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool >> >> ing >> >> >> >> A search for replication on the top of the doc page (ie >> >> http://www.postgresql.org/docs/8.4/interactive/index.html) takes to the high >> >> availability page, so a reference there to the wiki page may be a good idea. >> > >> > That is an excellent idea, not only for replication, but there are >> > probably other wiki pages that we should link to from our main docs. ?I >> > will go through the wiki, find appropriate pages, and add links from our >> > docs. >> >> I don't know that I'm eager to link from our docs to the wiki. That >> seems likely to lead to maintenance headaches. But on the other hand, >> I see no problem mentioning third-party products that are part of the >> PG ecosystem. > > Well, the problem is that we have more solutions that fit in the docs in > normal places. Isn't that just a matter of rejiggering the page formatting a little bit? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas wrote: > On Wed, May 26, 2010 at 5:45 PM, Bruce Momjian <bruce@momjian.us> wrote: > > Robert Haas wrote: > >> On Tue, May 25, 2010 at 2:15 PM, Bruce Momjian <bruce@momjian.us> wrote: > >> > Francisco Reyes wrote: > >> >> Bruce Momjian writes: > >> >> > >> >> > Well, I assumed "Londiste" head reached the level that we should mention > >> >> > it, but you are right on the floodgates issue. ?We do aleady mention > >> >> > many other replication solutions in other sections, so I didn't think > >> >> > >> >> Then perhaps all that is needed is to just link to the replication section > >> >> of the wiki: > >> >> http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool > >> >> ing > >> >> > >> >> A search for replication on the top of the doc page (ie > >> >> http://www.postgresql.org/docs/8.4/interactive/index.html) takes to the high > >> >> availability page, so a reference there to the wiki page may be a good idea. > >> > > >> > That is an excellent idea, not only for replication, but there are > >> > probably other wiki pages that we should link to from our main docs. ?I > >> > will go through the wiki, find appropriate pages, and add links from our > >> > docs. > >> > >> I don't know that I'm eager to link from our docs to the wiki. ?That > >> seems likely to lead to maintenance headaches. ?But on the other hand, > >> I see no problem mentioning third-party products that are part of the > >> PG ecosystem. > > > > Well, the problem is that we have more solutions that fit in the docs in > > normal places. > > Isn't that just a matter of rejiggering the page formatting a little bit? The point is that there is a lot of replication information I don't want to merge into that SGML page so even if we mention "Londiste", the wiki reference is still useful. I have the same problem with mentioning pooling in the docs --- there is no natural place to put it, but I can reference the wiki from the performance SGML docs. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
On 05/27/2010 04:22 AM, Bruce Momjian wrote: > Robert Haas wrote: >> On Wed, May 26, 2010 at 5:45 PM, Bruce Momjian<bruce@momjian.us> wrote: >>> Robert Haas wrote: >>>> On Tue, May 25, 2010 at 2:15 PM, Bruce Momjian<bruce@momjian.us> wrote: >>>>> Francisco Reyes wrote: >>>>>> Bruce Momjian writes: >>>>>> >>>>>>> Well, I assumed "Londiste" head reached the level that we should mention >>>>>>> it, but you are right on the floodgates issue. ?We do aleady mention >>>>>>> many other replication solutions in other sections, so I didn't think >>>>>> >>>>>> Then perhaps all that is needed is to just link to the replication section >>>>>> of the wiki: >>>>>> http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pool >>>>>> ing >>>>>> >>>>>> A search for replication on the top of the doc page (ie >>>>>> http://www.postgresql.org/docs/8.4/interactive/index.html) takes to the high >>>>>> availability page, so a reference there to the wiki page may be a good idea. >>>>> >>>>> That is an excellent idea, not only for replication, but there are >>>>> probably other wiki pages that we should link to from our main docs. ?I >>>>> will go through the wiki, find appropriate pages, and add links from our >>>>> docs. >>>> >>>> I don't know that I'm eager to link from our docs to the wiki. ?That >>>> seems likely to lead to maintenance headaches. ?But on the other hand, >>>> I see no problem mentioning third-party products that are part of the >>>> PG ecosystem. >>> >>> Well, the problem is that we have more solutions that fit in the docs in >>> normal places. >> >> Isn't that just a matter of rejiggering the page formatting a little bit? > > The point is that there is a lot of replication information I don't want > to merge into that SGML page so even if we mention "Londiste", the wiki > reference is still useful. I have the same problem with mentioning > pooling in the docs --- there is no natural place to put it, but I can > reference the wiki from the performance SGML docs. well the problem seems to be that we are basically trying to recreate the stuff on the wiki in the main docs in a way that might end up in being outdated all the time. I think that we need to draw a clear line where we do external links (random sites or the wiki) and internal docs. everything that is the core product needs to be in the main docs if we go above that (and that includes all the replication stuff and whatnot) we should just reference an external source (wiki.postgresql.org prefered - fallback to something else) but maintaining just some stuff in our own docs seems just wrong... Stefan
Stefan Kaltenbrunner wrote: > > The point is that there is a lot of replication information I don't want > > to merge into that SGML page so even if we mention "Londiste", the wiki > > reference is still useful. I have the same problem with mentioning > > pooling in the docs --- there is no natural place to put it, but I can > > reference the wiki from the performance SGML docs. > > well the problem seems to be that we are basically trying to recreate > the stuff on the wiki in the main docs in a way that might end up in > being outdated all the time. > I think that we need to draw a clear line where we do external links > (random sites or the wiki) and internal docs. everything that is the > core product needs to be in the main docs if we go above that (and that > includes all the replication stuff and whatnot) we should just reference > an external source (wiki.postgresql.org prefered - fallback to something > else) but maintaining just some stuff in our own docs seems just wrong... Yea, the wiki information is far too bulky to fit into our docs, and maintaining it in our docs isn't worthwhile because it is more _suggestions_ than critical information. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
On Thu, May 27, 2010 at 11:14:48PM -0400, Bruce Momjian wrote: > Stefan Kaltenbrunner wrote: > > > The point is that there is a lot of replication information I don't want > > > to merge into that SGML page so even if we mention "Londiste", the wiki > > > reference is still useful. I have the same problem with mentioning > > > pooling in the docs --- there is no natural place to put it, but I can > > > reference the wiki from the performance SGML docs. > > > > well the problem seems to be that we are basically trying to recreate > > the stuff on the wiki in the main docs in a way that might end up in > > being outdated all the time. > > I think that we need to draw a clear line where we do external links > > (random sites or the wiki) and internal docs. everything that is the > > core product needs to be in the main docs if we go above that (and that > > includes all the replication stuff and whatnot) we should just reference > > an external source (wiki.postgresql.org prefered - fallback to something > > else) but maintaining just some stuff in our own docs seems just wrong... > > Yea, the wiki information is far too bulky to fit into our docs, and > maintaining it in our docs isn't worthwhile because it is more > _suggestions_ than critical information. Perhaps the docs should just say exactly that: The PostgreSQL community has developed a wide variety of additional software and made it available for general use. This documentation describes only the software in the "core" PostgreSQL distribution (comprising the server, a set of client programs, and the contrib packages), and does not attempt to document this additional software in any detail. Interested readers are advised to consult the PostgreSQL wiki at http://wiki.postgresql.org for further details ISTM there's a page somewhere on the wiki that tries to be a comprehensive listing of add-ons, but I can't find it. Maybe that page ought to get special mention in such documentation. -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com
Attachment
Bruce Momjian wrote: > That is an excellent idea, not only for replication, but there are > probably other wiki pages that we should link to from our main docs. I > will go through the wiki, find appropriate pages, and add links from our > docs. > Please suggest what those pages are before you do the doc edits. While we can fix stuff with redirection, in some cases it would be better to create a specific destination page for the documentation to point to, with a stable URL from the beginning. For example, the last specific page we would want to point the docs toward is http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Pooling , which is ridiculous in length (I regret creating the page like that), going through a major revision right now (parallel descriptions being worked out at http://wiki.postgresql.org/wiki/Clustering ), and just generally a mess. I'd rather see (and will create) specific pages created for Replication and Pooling if we want something the docs can be pointed towards. As an example, I already created one such page but haven't filled in the details for the Nagios etc. doc updates Bruce already inserted: http://wiki.postgresql.org/wiki/Monitoring. It's really obvious that PostgreSQL installs in the real world benefit from adding a number of non-core tools. It's inappropriate and overwhelming to consider documenting them, or even listing them all, in the core docs. It's also terrible that we don't make it easier for people to find those, and point out the seams where it's expected a third party package will fill in on something that's been punted out of core but is done well outside of it. The wiki is a reasonable place to assemble both a highlights directory of such packages and associated documentation, all in one spot. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
Greg Smith wrote: > Bruce Momjian wrote: > > That is an excellent idea, not only for replication, but there are > > probably other wiki pages that we should link to from our main docs. I > > will go through the wiki, find appropriate pages, and add links from our > > docs. > > > > Please suggest what those pages are before you do the doc edits. While > we can fix stuff with redirection, in some cases it would be better to > create a specific destination page for the documentation to point to, > with a stable URL from the beginning. For example, the last specific > page we would want to point the docs toward is > http://wiki.postgresql.org/wiki/Replication%2C_Clustering%2C_and_Connection_Pooling > , which is ridiculous in length (I regret creating the page like that), > going through a major revision right now (parallel descriptions being > worked out at http://wiki.postgresql.org/wiki/Clustering ), and just > generally a mess. > > I'd rather see (and will create) specific pages created for Replication > and Pooling if we want something the docs can be pointed towards. As an > example, I already created one such page but haven't filled in the > details for the Nagios etc. doc updates Bruce already inserted: > http://wiki.postgresql.org/wiki/Monitoring. > > It's really obvious that PostgreSQL installs in the real world benefit > from adding a number of non-core tools. It's inappropriate and > overwhelming to consider documenting them, or even listing them all, in > the core docs. It's also terrible that we don't make it easier for > people to find those, and point out the seams where it's expected a > third party package will fill in on something that's been punted out of > core but is done well outside of it. The wiki is a reasonable place to > assemble both a highlights directory of such packages and associated > documentation, all in one spot. OK, let me troll around and find too pages. Is there a good way to review all the useful ones? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com