Re: [DOCS] [HACKERS] Replication documentation addition
On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. I thought that was implied in the early paragraph about why there are many solutions. I think we should explicitely spell it out, especially considering how many times people ask about it. How about... This multitude of choices is why PostgreSQL does not ship with a replication solution by default; any bundled solution would only satisfy a subset of replication needs. (sorry for the non-standard patch, but anoncvs isn't sync'd up yet). -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) *** failover.sgml.org Thu Oct 26 10:32:45 2006 --- failover.sgml Thu Oct 26 10:55:03 2006 *** *** 29,35 working together. Because there is no single solution that eliminates the impact of the sync problem for all use cases, there are multiple solutions. Each solution addresses this problem in a different way, and ! minimizes its impact for a specific workload. /para para --- 29,37 working together. Because there is no single solution that eliminates the impact of the sync problem for all use cases, there are multiple solutions. Each solution addresses this problem in a different way, and ! minimizes its impact for a specific workload. This multitude of choices is ! why PostgreSQL does not ship with a replication solution by default; any ! bundled solution would only satisfy a subset of replication needs. /para para ---(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] Replication documentation addition
Jim C. Nasby wrote: On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. I thought that was implied in the early paragraph about why there are many solutions. I think we should explicitely spell it out, especially considering how many times people ask about it. How about... This multitude of choices is why PostgreSQL does not ship with a replication solution by default; any bundled solution would only satisfy a subset of replication needs. The problem is that we do have some solutions in our code, like doing data partitioning in the application, warm standby, or using a shared disk for failover, so how do we spell that out? I say there are multiple solutions, but I don't see how I can say that all are external and not included. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] [HACKERS] Replication documentation addition
Joshua D. Drake wrote: Bruce Momjian wrote: Jim C. Nasby wrote: On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. I thought that was implied in the early paragraph about why there are many solutions. I think we should explicitely spell it out, especially considering how many times people ask about it. How about... This multitude of choices is why PostgreSQL does not ship with a replication solution by default; any bundled solution would only satisfy a subset of replication needs. The problem is that we do have some solutions in our code, like doing data partitioning in the application, warm standby, or using a shared disk for failover, so how do we spell that out? I say there are multiple solutions, but I don't see how I can say that all are external and not included. None of those are replication solutions. So I would have to agree with Jim here. This isn't about what people do with their app, so that is not relevant. Warm standby is PITR which is a backup and recovery solution. It does not include a failover solution and is *not* replication. It technically does not provide an HA solution either as it will be almost always farther behind than a replication solution. Shared disk for failover could be used by anything it isn't special to a replication scenario it is standard for many HA. The section is no longer titled only replication, but is now Failover, Replication, Load Balancing, and Clustering Options, so it is more a catch-all, and hence saying nothing is included doesn't make sense. You could say no replication is included, but replication is only one part of the section, so where do you put that, and why is it worth it? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
Bruce Momjian wrote: Jim C. Nasby wrote: On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. I thought that was implied in the early paragraph about why there are many solutions. I think we should explicitely spell it out, especially considering how many times people ask about it. How about... This multitude of choices is why PostgreSQL does not ship with a replication solution by default; any bundled solution would only satisfy a subset of replication needs. The problem is that we do have some solutions in our code, like doing data partitioning in the application, warm standby, or using a shared disk for failover, so how do we spell that out? I say there are multiple solutions, but I don't see how I can say that all are external and not included. None of those are replication solutions. So I would have to agree with Jim here. This isn't about what people do with their app, so that is not relevant. Warm standby is PITR which is a backup and recovery solution. It does not include a failover solution and is *not* replication. It technically does not provide an HA solution either as it will be almost always farther behind than a replication solution. Shared disk for failover could be used by anything it isn't special to a replication scenario it is standard for many HA. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(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] Replication documentation addition
The documentation comes with the open source tarball. Yuck. I would welcome if the docs point to an unofficial wiki (maintained externally from authoritative PostgreSQL developers) or a website listing them and giving a brief of each solution. postgresql.org already does this for events (commercial training!) and news. Point to postgresql.org/download/commercial as there *already* are brief descriptions, pricing and website links. I wouldn't have looked in download for such a thing. Nor would I expect everyone with a Postgres related solution to want to post it on PosgreSql.org for download. However I agree that a simple web page listing such things is needed. It's easy to manage - way easier to manage than the development of a competent relational database engine! It's just a bunch of text, after all, and errors aren't that critical and will tend to self-correct through user attention. You list the ones that are stable in their existence (commercial or not). And how would you determine it? Years of existance? Contribution to PostgreSQL's source code? It is not easy and wouldn't be fair. There are ones that certainly will be listed, and other doubtful ones (which would perhaps complain, that's why I said 'all' - if they are not stable, either they stay out of the market or fix their problems). You have to just trust people. If it's clear that this isn't PostgreSql.org, stuff can be unstable, etc - it isn't the group's problem. No it doesn't. Because there is always the, It want's to be free! crowd. Yes, I agree there are. But also development in *that* cutting-edge is scarce. It feels that something had filled the gap if you list some commercial solution, mainly people in the trenches (DBAs). They would, obviously, firstly seek the commercial solutions as they are interested. So they click 'commercial products' in the main website. Not necessarily. Most times, I'll seek the better solution, which may or may not be commercial. Sometimes I'll avoid a commercial version because I don't like the company! ... But getting genuine donations of time - without direct $$ self-interest attached, is a whole nother kettle o fish. For example, there are a lot of students out there that are excellent and would love to have a mechanism to gain something for their resumes before entering the business world. ...There might be some residual interest at UCB, for example. Attracting this kind of support is a completely different dialogue, but on _this_ topic, surely seeking the it wants to be free! crowd can't (or shouldn't, in my view) be used as an excuse for not publishing pointers to commercial soltions that involve PostgreSql. Do it already! If people (who read the documentation) professionally work with PostgreSQL, they may already have been briefed by those commercial offerings in some way. Maybe, maybe not. The may is a wiggler; sounds like an excuse with a back door. The real answer is probably not! I'm in that world. I haven't been briefed. Ever. And I agree with your point, still. However, that would open a precedent for people to have to maintain lists of stable software in every documentation area. All that's needed is ONE list, with clear disclaimer. It'll be all text and links, and maybe the odd small .gif logo, if permitted, so it won't be a huge thing. Come on now, are there thousands of such products? Tens sounds more plausible. Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
On Thu, Oct 26, 2006 at 11:59:57AM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. I thought that was implied in the early paragraph about why there are many solutions. I think we should explicitely spell it out, especially considering how many times people ask about it. How about... This multitude of choices is why PostgreSQL does not ship with a replication solution by default; any bundled solution would only satisfy a subset of replication needs. The problem is that we do have some solutions in our code, like doing data partitioning in the application, warm standby, or using a shared disk for failover, so how do we spell that out? I say there are multiple solutions, but I don't see how I can say that all are external and not included. Good point... how about this? -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) Index: doc/src/sgml/failover.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/failover.sgml,v retrieving revision 1.2 diff -c -r1.2 failover.sgml *** doc/src/sgml/failover.sgml 26 Oct 2006 17:07:03 - 1.2 --- doc/src/sgml/failover.sgml 26 Oct 2006 18:26:21 - *** *** 29,35 working together. Because there is no single solution that eliminates the impact of the sync problem for all use cases, there are multiple solutions. Each solution addresses this problem in a different way, and ! minimizes its impact for a specific workload. /para para --- 29,40 working together. Because there is no single solution that eliminates the impact of the sync problem for all use cases, there are multiple solutions. Each solution addresses this problem in a different way, and ! minimizes its impact for a specific workload. A few of these solutions are ! provided with PostgreSQL itself, but it would be impractical for the core ! database to handle every scenario. That is why most solutions are implemented ! outside the database. PostgreSQL's unique extensibility is what allows this ! to happen, and 3rd-party solutions should not be thought of as ! qoutesecond-rate/ simply because they are not bundled with the database. /para para ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] [HACKERS] Replication documentation addition
Jim C. Nasby wrote: On Thu, Oct 26, 2006 at 11:59:57AM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: On Wed, Oct 25, 2006 at 08:42:07PM -0400, Bruce Momjian wrote: Jim C. Nasby wrote: Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. I thought that was implied in the early paragraph about why there are many solutions. I think we should explicitely spell it out, especially considering how many times people ask about it. How about... This multitude of choices is why PostgreSQL does not ship with a replication solution by default; any bundled solution would only satisfy a subset of replication needs. The problem is that we do have some solutions in our code, like doing data partitioning in the application, warm standby, or using a shared disk for failover, so how do we spell that out? I say there are multiple solutions, but I don't see how I can say that all are external and not included. Good point... how about this? Sorry, that is too preachy, and I have the extensibility issue addressed in the commerical solutions section. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
Hi, I also wrote Bruce about that. It happens that, if you 'freely advertise' commercial solutions (rather than they doing so by other vehicles) you will always happen to be an 'updater' to the docs if they change their product lines, if they change their business model, if and if. If you cite a commercial solution, as a fair game you should cite *all* of them. If one enterprise has the right to be listed in the documentation, all of them might, as you will never be favouring one of them. That's the main motivation to write this. Moreover, if there are also commercial solutions for high-end installs and they are cited as providers to those solutions, it (to a point) disencourages those of gathering themselves and writing open source extensions to PostgreSQL. As Bruce stated, then should the documentation contemplate EnterpriseDB's Oracle functions? Should PostgreSQL also come with it? Wouldn't it be painful to make, say, another description for an alternate product other than EnterpriseDB if it arises? If people (who read the documentation) professionally work with PostgreSQL, they may already have been briefed by those commercial offerings in some way. I think only the source and its tightly coupled (read: can compile along with, free as PostgreSQL) components should be packaged into the tarball. However, I find Bruce's unofficial wiki idea a good one for comparisons. Regards, Cesar Steve Atkins wrote: On Oct 24, 2006, at 9:20 PM, Bruce Momjian wrote: Steve Atkins wrote: If we are to add them, I need to hear that from people who haven't worked in PostgreSQL commerical replication companies. I'm not coming to PostgreSQL for open source solutions. I'm coming to PostgreSQL for _good_ solutions. I want to see what solutions might be available for a problem I have. I certainly want to know whether they're freely available, commercial or some flavour of open source, but I'd like to know about all of them. A big part of the value of Postgresql is the applications and extensions that support it. Hiding the existence of some subset of those just because of the way they're licensed is both underselling postgresql and doing something of a disservice to the user of the document. OK, does that mean we mention EnterpriseDB in the section about Oracle functions? Why not mention MS SQL if they have a better solution? I just don't see where that line can clearly be drawn on what to include. Do we mention Netiza, which is loosely based on PostgreSQL? It just seems very arbitrary to include commercial software. If someone wants to put in on a wiki, I think that would be fine because that doesn't seems as official. Good question. The line needs to be drawn somewhere. It's basically your judgement, tempered by other peoples feedback, though. If it were me, I'd ask myself Would I mention this product if it were open source? Would mentioning it help people using the document?. Cheers, Steve ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
Hi, Bruce Momjian wrote: I have updated the text. Please let me know what else I should change. I am unsure if I should be mentioning commercial PostgreSQL products in our documentation. I support your POV and vote for not including any pointers to commercial extensions in the official documentation. If at all, they should go to 'external-projects.sgml', where PostGIS, PgAdmin and other projects are mentioned. I can't really get excited about the exclusion of the term 'replication', because it's what most people are looking for. It's a well known term. Sorry if it sounded that way, but I've not meant to avoid that term. The newly created terms 'Query Broadcast Load Balancing' or even worse 'Multi-Master Load Balancing' are more confusing than helpful, because these terms do not exist. (See the googlefight in [1]) Can we name the chapter Fail-over, Load-Balancing and Replication Options? That would fit everything and contain the necessary buzz words. Also, I'm still missing Multi- vs Single-Master, which are also commonly used terms. IMHO, it does not make sense to speak of a synchronous replication for a 'Shared Disk Fail Over'. It's not replication, because there's no replica. The Data Partitioning paragraph should probably mention it's close relation with data partitioning across table spaces (and make the differences clear). What you call 'Query Broadcast Load Balancing' is also a multi-master replication, thus naming only the later 'Multi-Master Load Balancing' misleading. I'd propose to add a subsection 'Synchronous, Multi-Master Replication' and explain the different possibilities on how to do that: * Query-Based * with 2PC * Distributed SHMEM * (perhaps mention the optimized Postgres-R algorithm ;-) What you called 'Single-Query Clustering' is probably better known as 'Parallel Query Execution'. It can be combined with all types of replication (every combination of async / sync and Single- / Multi-Master). It's maybe load balancing, but it depends on some form of replication to distribute the data first. I liked Chris Browns documentation in [2] which was clearer regarding replication (which can be used to do fail-over, load-balancing, data-partitioning or parallel query execution). I'd like to keep all those things a little more separate to get them clear. Regards Markus [1]: Googlefight: Multi-Master Load Balancing vs Multi-Master Replication: http://tinyurl.com/y3k76r [2]: Chris Browns proposal for a replication documentation: http://archives.postgresql.org/pgsql-patches/2006-08/msg00026.php ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] [HACKERS] Replication documentation addition
I don't think the PostgreSQL documentation should be mentioning commercial solutions. I think maybe the PostgreSQL documentation should be careful about trying to list a complete list of commercial *or* free solutions. Instead linking to something on the main website or on techdocs that can more easily be updated. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Bruce Momjian wrote: OK, does that mean we mention EnterpriseDB in the section about Oracle functions? Why not mention MS SQL if they have a better solution? I just don't see where that line can clearly be drawn on what to include. Do we mention Netiza, which is loosely based on PostgreSQL? It just seems very arbitrary to include commercial software. If someone wants to put in on a wiki, I think that would be fine because that doesn't seems as official. I agree that the commercial offerings shouldn't be named directly in the docs, but it should be mentioned that some commercial options are available and a starting point to find more information. If potential new users look through the docs and it says no options available for what they want or consider they will need in the future then they go elsewhere, if they know that some options are available then they will look further if they want that feature. something like There are currently no open source solutions available for this option but there are some commercial offerings. More details of some available solutions can be found at postgresql.org/support/ -- Shane Ambler [EMAIL PROTECTED] Get Sheeky @ http://Sheeky.Biz ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
On Wed, Oct 25, 2006 at 08:22:25PM +0930, Shane Ambler wrote: Bruce Momjian wrote: OK, does that mean we mention EnterpriseDB in the section about Oracle functions? Why not mention MS SQL if they have a better solution? I just don't see where that line can clearly be drawn on what to include. Do we mention Netiza, which is loosely based on PostgreSQL? It just seems very arbitrary to include commercial software. If someone wants to put in on a wiki, I think that would be fine because that doesn't seems as official. I agree that the commercial offerings shouldn't be named directly in the docs, but it should be mentioned that some commercial options are available and a starting point to find more information. If potential new users look through the docs and it says no options available for what they want or consider they will need in the future then they go elsewhere, if they know that some options are available then they will look further if they want that feature. something like There are currently no open source solutions available for this option but there are some commercial offerings. More details of some available solutions can be found at postgresql.org/support/ I think this is probably the best compromise. Keep in mind that many people who are looking at us will also be looking at MySQL, which is itself a commercial offering. It's good to let folks know that with PostgreSQL, they have more control over how much money they spend for commercial add-ons and support. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote: I can't really get excited about the exclusion of the term 'replication', because it's what most people are looking for. It's a well known term. Sorry if it sounded that way, but I've not meant to avoid that term. snip IMHO, it does not make sense to speak of a synchronous replication for a 'Shared Disk Fail Over'. It's not replication, because there's no replica. Those to statements are at odds with each other, at least based on everyone I've ever talked to in a commercial setting. People will use terms like 'replication', 'HA' or 'clustering' fairly interchangably. Usually what these folks want is some kind of high-availability solution. A few are more concerned with scalability. Sometimes it's a combination of both. That's why I think it's good for the chapter to deal with both aspects of this. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] [HACKERS] Replication documentation addition
I am not inclined to add commercial offerings. If people wanted commercial database offerings, they can get them from companies that advertize. People are coming to PostgreSQL for open source solutions, and I think mentioning commercial ones doesn't make sense. If we are to add them, I need to hear that from people who haven't worked in PostgreSQL commerical replication companies. You did, Josh Berkus. Secondly, as many people have stated in the past not one replication suits everyone's needs and as PostgreSQL has many replication solutions, it only makes sense to list the more prominent ones, commercial or not. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
A big part of the value of Postgresql is the applications and extensions that support it. Hiding the existence of some subset of those just because of the way they're licensed is both underselling postgresql and doing something of a disservice to the user of the document. OK, does that mean we mention EnterpriseDB in the section about Oracle functions? Way to compare apples to houses their Bruce. We are talking about *PostgreSQL* replication solutions. Not *Oracle* compatibility functions, However, *if* we had an Oracle compatibility section, I would say, Yes it does make sense to list EnterpriseDB as a Proprietary Commercial solution to migrating from Oracle. Why not mention MS SQL if they have a better solution? Because we aren't talking about MS SQL, we are talking about PostgreSQL. I just don't see where that line can clearly be drawn on what to include. Do we mention Netiza, which is loosely based on PostgreSQL? It just seems very arbitrary to include commercial software. It is no more arbitrary than including *any* information on PostgreSQL replication solutions, because PostgreSQL doesn't have any. PostgreSQL doesn't do replication, except for PITR (and that is pushing it as a replication solution). Now.. there are *projects* that enable PostgreSQL to do replication. Some of them are Open Source, some of them are commercial products. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Hi, Cesar, Cesar Suga wrote: If people (who read the documentation) professionally work with PostgreSQL, they may already have been briefed by those commercial offerings in some way. I think only the source and its tightly coupled (read: can compile along with, free as PostgreSQL) components should be packaged into the tarball. However, I find Bruce's unofficial wiki idea a good one for comparisons. My suggestion is that the docs should mention only the pure existence of important third-party packages and projects in those places where it talks about the deficits that are supposedly fixed by those. E. G. There are some third-party packages and projects that aim to provide multi-master replication, you can search for more information at http://[unofficial wiki page url] or your favourite search engine. This way, the docs stay neutral, but point the user to possible solutions of his problem. HTH, Markus -- Markus Schaber | Logical TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org signature.asc Description: OpenPGP digital signature
Re: [DOCS] [HACKERS] Replication documentation addition
Cesar Suga wrote: Hi, I also wrote Bruce about that. It happens that, if you 'freely advertise' commercial solutions (rather than they doing so by other vehicles) you will always happen to be an 'updater' to the docs if they change their product lines, if they change their business model, if and if. That is no different than the open source offerings. We have had several open source offerings that have died over the years. Replicator, for example has always been Replicator and has been around longer than any of the current replication solutions. If you cite a commercial solution, as a fair game you should cite *all* of them. No. That doesn't make any sense either. I assume we aren't going to list all PostgreSQL OSS replication solutions (there are at least a dozen or more). You list the ones that are stable in their existence (commercial or not). If one enterprise has the right to be listed in the documentation, all of them might, as you will never be favouring one of them. You are looking at this the wrong way. This isn't about *any* enterprise. It is about a PostgreSQL Solution. There happens to be two or three known working open source solutions, and two or three known working commercial solutions. That's the main motivation to write this. Moreover, if there are also commercial solutions for high-end installs and they are cited as providers to those solutions, it (to a point) disencourages those of gathering themselves and writing open source extensions to PostgreSQL. No it doesn't. Because there is always the, It want's to be free! crowd. If people (who read the documentation) professionally work with PostgreSQL, they may already have been briefed by those commercial offerings in some way. Maybe, maybe not. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
I would think that companies that sell closed-source solutions for PostgreSQL would be modest enough not to push their own agenda for the documentation. I think they should just sit back and hope others suggest it. [ Josh Berkus recently left Green Plum for Sun. ] --- Joshua D. Drake wrote: A big part of the value of Postgresql is the applications and extensions that support it. Hiding the existence of some subset of those just because of the way they're licensed is both underselling postgresql and doing something of a disservice to the user of the document. OK, does that mean we mention EnterpriseDB in the section about Oracle functions? Way to compare apples to houses their Bruce. We are talking about *PostgreSQL* replication solutions. Not *Oracle* compatibility functions, However, *if* we had an Oracle compatibility section, I would say, Yes it does make sense to list EnterpriseDB as a Proprietary Commercial solution to migrating from Oracle. Why not mention MS SQL if they have a better solution? Because we aren't talking about MS SQL, we are talking about PostgreSQL. I just don't see where that line can clearly be drawn on what to include. Do we mention Netiza, which is loosely based on PostgreSQL? It just seems very arbitrary to include commercial software. It is no more arbitrary than including *any* information on PostgreSQL replication solutions, because PostgreSQL doesn't have any. PostgreSQL doesn't do replication, except for PITR (and that is pushing it as a replication solution). Now.. there are *projects* that enable PostgreSQL to do replication. Some of them are Open Source, some of them are commercial products. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
Bruce Momjian wrote: I would think that companies that sell closed-source solutions for PostgreSQL would be modest enough not to push their own agenda for the documentation. I think they should just sit back and hope others suggest it. [ Josh Berkus recently left Green Plum for Sun. ] Bruce, you are making an idiot of yourself. With this statement you have implied that Josh Berkus, are core member somehow has his own agenda that is not in the interests of the PostgreSQL community. Further that, you are suggesting that I as a member of Command Prompt has an agenda that is not in the interests of the PostgreSQL community. It was rude, uncalled for, inaccurate, and frankly disgusting. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
I also wrote Bruce about that. It happens that, if you 'freely advertise' commercial solutions (rather than they doing so by other vehicles) you will always happen to be an 'updater' to the docs if they change their product lines, if they change their business model, if and if. That is no different than the open source offerings. We have had several open source offerings that have died over the years. Replicator, for example has always been Replicator and has been around longer than any of the current replication solutions. I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. And that can contain both free and non-free projects, under clear headlines showing the difference. The documentation is about PostgreSQL, not about third-party products, be they free or commercial. Our *website*, however, should give guidance on which specific products we (as a community) know are stable and usable along with PostgreSQL (as we do today under downloads, but could very well do based on specific uses like replication as well) //Magnus ---(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] Replication documentation addition
they change their business model, if and if. That is no different than the open source offerings. We have had several open source offerings that have died over the years. Replicator, for example has always been Replicator and has been around longer than any of the current replication solutions. I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. And that can contain both free and non-free projects, under clear headlines showing the difference. The documentation is about PostgreSQL, not about third-party products, be they free or commercial. Our *website*, however, should give guidance on which specific products we (as a community) know are stable and usable along with PostgreSQL (as we do today under downloads, but could very well do based on specific uses like replication as well) I can agree with this :) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
Magnus Hagander [EMAIL PROTECTED] writes: I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. I agree with that. If we have statements about other projects in our docs, we will have a problem with not being able to update those statements in a timely fashion when the other projects change. regards, tom lane ---(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] Replication documentation addition
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. I agree with that. If we have statements about other projects in our docs, we will have a problem with not being able to update those statements in a timely fashion when the other projects change. This being said, I would say that the replication documentation needs to be on Techdocs or some place similar and that we should have a link in the PostgreSQL docs that points to the techdocs article and possibly: http://www.postgresql.org/download/ . Sincerely, Joshua D. Drake regards, tom lane ---(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 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
Markus Schiltknecht wrote: Hi, Bruce Momjian wrote: I have updated the text. Please let me know what else I should change. I am unsure if I should be mentioning commercial PostgreSQL products in our documentation. I support your POV and vote for not including any pointers to commercial extensions in the official documentation. If at all, they should go to 'external-projects.sgml', where PostGIS, PgAdmin and other projects are mentioned. I can't really get excited about the exclusion of the term 'replication', because it's what most people are looking for. It's a well known term. Sorry if it sounded that way, but I've not meant to avoid that term. OK, I have re-added the term replication as appropriate. The newly created terms 'Query Broadcast Load Balancing' or even worse 'Multi-Master Load Balancing' are more confusing than helpful, because these terms do not exist. (See the googlefight in [1]) OK, renamed. Can we name the chapter Fail-over, Load-Balancing and Replication Options? That would fit everything and contain the necessary buzz words. Yes. Done, cluster added too. Also, I'm still missing Multi- vs Single-Master, which are also commonly used terms. Yea, not sure how to get those in because it somewhat confuses the purpose of the solution. IMHO, it does not make sense to speak of a synchronous replication for a 'Shared Disk Fail Over'. It's not replication, because there's no replica. Agreed. Modified. The Data Partitioning paragraph should probably mention it's close relation with data partitioning across table spaces (and make the differences clear). Uh, so you I/O load with table spaces. Uh, that seems too far a reach to mention here. What you call 'Query Broadcast Load Balancing' is also a multi-master replication, thus naming only the later 'Multi-Master Load Balancing' misleading. Renamed. I'd propose to add a subsection 'Synchronous, Multi-Master Replication' and explain the different possibilities on how to do that: * Query-Based * with 2PC * Distributed SHMEM * (perhaps mention the optimized Postgres-R algorithm ;-) What you called 'Single-Query Clustering' is probably better known as 'Parallel Query Execution'. It can be combined with all types of replication (every combination of async / sync and Single- / Multi-Master). It's maybe load balancing, but it depends on some form of replication to distribute the data first. Good term. Added. I liked Chris Browns documentation in [2] which was clearer regarding replication (which can be used to do fail-over, load-balancing, data-partitioning or parallel query execution). I'd like to keep all those things a little more separate to get them clear. Please let me know how you like the new version at the ftp URL. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
Jim C. Nasby wrote: On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote: I can't really get excited about the exclusion of the term 'replication', because it's what most people are looking for. It's a well known term. Sorry if it sounded that way, but I've not meant to avoid that term. snip IMHO, it does not make sense to speak of a synchronous replication for a 'Shared Disk Fail Over'. It's not replication, because there's no replica. Those to statements are at odds with each other, at least based on everyone I've ever talked to in a commercial setting. People will use terms like 'replication', 'HA' or 'clustering' fairly interchangably. Usually what these folks want is some kind of high-availability solution. A few are more concerned with scalability. Sometimes it's a combination of both. That's why I think it's good for the chapter to deal with both aspects of this. OK, I did break it out somewhat for clarity. Let me know how it looks now. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Hi, Jim C. Nasby wrote: Those to statements are at odds with each other, at least based on everyone I've ever talked to in a commercial setting. People will use terms like 'replication', 'HA' or 'clustering' fairly interchangably. Usually what these folks want is some kind of high-availability solution. A few are more concerned with scalability. Sometimes it's a combination of both. That's why I think it's good for the chapter to deal with both aspects of this. Yabut... at least the PostgreSQL manual should uses the terms correctly. And while I do perfectly agree that it's a fail-over solution and it should be mentioned in that section, I'm arguing that it's not replication. Regards Markus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. I agree with that. If we have statements about other projects in our docs, we will have a problem with not being able to update those statements in a timely fashion when the other projects change. I mention only Slony and pgpool as examples of replication types. They seem to have risen to high enough visiblity to do that. I have not mentioned any other solutions. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
Bruce Momjian wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. I agree with that. If we have statements about other projects in our docs, we will have a problem with not being able to update those statements in a timely fashion when the other projects change. I mention only Slony and pgpool as examples of replication types. They seem to have risen to high enough visiblity to do that. I have not mentioned any other solutions. What about Slony-II or pgpool2? Which are fundamentally different from their v1 counterparts (o.k. slony-ii isn't out yet but still). I +1 that we move to have all of the replication documentation pushed to techdocs or other facility and just have a link from the docs. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Joshua D. Drake wrote: Bruce Momjian wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. I agree with that. If we have statements about other projects in our docs, we will have a problem with not being able to update those statements in a timely fashion when the other projects change. I mention only Slony and pgpool as examples of replication types. They seem to have risen to high enough visiblity to do that. I have not mentioned any other solutions. What about Slony-II or pgpool2? Which are fundamentally different from their v1 counterparts (o.k. slony-ii isn't out yet but still). I +1 that we move to have all of the replication documentation pushed to techdocs or other facility and just have a link from the docs. What I did was to mention Slony and pgpool as examples, so people realize there are many other soluions. It would be good to have a companion web site that could list them all, both open source and commercial. That is going to take a lot more work, but I think would have great value, especially since our documentation will clearly outline the terms. What you don't want to do is to throw up a list and have people try to figure out what solutions they cover. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote: Can we name the chapter Fail-over, Load-Balancing and Replication Options? That would fit everything and contain the necessary buzz words. ... IMHO, it does not make sense to speak of a synchronous replication for a 'Shared Disk Fail Over'. It's not replication, because there's no replica. As you point out, there is no replica of the data, but there is some protection against machine failure, which puts it firmly in the Fail-over part above. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] [HACKERS] Replication documentation addition
David Fetter wrote: On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote: Can we name the chapter Fail-over, Load-Balancing and Replication Options? That would fit everything and contain the necessary buzz words. ... IMHO, it does not make sense to speak of a synchronous replication for a 'Shared Disk Fail Over'. It's not replication, because there's no replica. As you point out, there is no replica of the data, but there is some protection against machine failure, which puts it firmly in the Fail-over part above. Right, but his point was not to call it synchronous. I have fixed that in the current version. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Totally agree. The docs will tend to outlive whatever projects or websites they mention. Best to not bake that into stone. -Casey On Oct 25, 2006, at 3:36 AM, Magnus Hagander wrote: I don't think the PostgreSQL documentation should be mentioning commercial solutions. I think maybe the PostgreSQL documentation should be careful about trying to list a complete list of commercial *or* free solutions. Instead linking to something on the main website or on techdocs that can more easily be updated. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
On 10/25/06, Bruce Momjian [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: Bruce Momjian wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I think this is a good reason not to list *any* of the products by name in the documentation, but instead refer to a page on say techdocs that can be more easily updated. I agree with that. If we have statements about other projects in our docs, we will have a problem with not being able to update those statements in a timely fashion when the other projects change. I mention only Slony and pgpool as examples of replication types. They seem to have risen to high enough visiblity to do that. I have not mentioned any other solutions. What about Slony-II or pgpool2? Which are fundamentally different from their v1 counterparts (o.k. slony-ii isn't out yet but still). I +1 that we move to have all of the replication documentation pushed to techdocs or other facility and just have a link from the docs. What I did was to mention Slony and pgpool as examples, so people realize there are many other soluions. It would be good to have a companion web site that could list them all, both open source and commercial. That is going to take a lot more work, but I think would have great value, especially since our documentation will clearly outline the terms. What you don't want to do is to throw up a list and have people try to figure out what solutions they cover. I'm in quite an unique situation right now, working with a few DBAs who have deep knowledge but no PostgreSQL background, so I have a good view how PostgreSQL is perceived by people with fair knowledge of other databases. What I have noticed is a deep respect for community. If they ask about replication solution, and I tell about Slony, they ask if Slony is provided with the postgresql-contrib. Well... no, and it won't be. Then they look back, think a while and say somethig on the lines of: well, $SOME_OTHER _DATABASE was using external replication solutions so it is all right. But then, before I talked with them, they did some quick research on PostgreSQL and their perception was that there's no replication / replication is shady in PostgreSQL. It would be quite convenient to tell them: No replication? Did you actually read the manual? here goes URL Well, pointing them to slony page is a solution but of a lesser caliber (how should they know about Slony anyway? They are newbies). Pointing them at The Documentation is a Good Argument (and it may cause them to look for some other information, like SQL syntax or PostgreSQL-specific catalog views there, which is Good). Enough background. Bruce, I've read Your documentation and I was left a bit with a feeling that it's a bit too generic. It's almost as if it could be about just about any major database, not PostgreSQL specific. I feel that, when I'm reading PostgreSQL docs I would like to know how to set up multi-master replication with PostgreSQL not an explanation what a multi-master replication is. It's not about the actual documentation content, but rather on accents distribution. Now it is something like: These are the types of replication solutions possible, some of them can be done with PostgreSQL, I think it should be rather: With PostgreSQL and some third-party tools you can achieve such and such replication solutions, oh and by the way, research is done on such and such replication method, but it's not a production quality yet. And I try to think as my DBA-mates would do if they read the documentation, I'm not sure they would end up enlighted after reading the docs -- thay would probably say: hey, I knew that, it's well structured there, but I still don't know what should I use, or maybe where can I read something about this slony thing anyway?. It may be my closed thinking schema though. What I feel is that such outsider, after reading these docs should end with Aha! I should be using Slony for my purposes. Or pgpool, if it's what she needs. I believe Tom's remark that it does NOT belong in the PostgreSQL documentation is quite right (though I wish there IS some reference to external replication packages, mainly because over and over again I need to prove PostgreSQL CAN be replicated, and it's not uncommon). However I'm still unconvinced about TechDocs -- TechDocs are good but still they are a bit scattered and unorganised. I am a PostgreSQL enthusiast, but it took me a while to learn about them, and for newbies not biased towards PostgreSQL it may take even more time. If it is linked from within the documentation, random DBAs might read it, and I wish they do. Right now I am more and more biased towards an additional documentation book for PostgreSQL, something like DBA guide or handbook. In format similar to the PostgreSQL documentation, but inside oriented around configuring other tools around and together with PostgreSQL. I shall send here some drafts withing 10-days time to seed a
Re: [DOCS] [HACKERS] Replication documentation addition
Dawid Kuroczko wrote: Bruce, I've read Your documentation and I was left a bit with a feeling that it's a bit too generic. It's almost as if it could be about just about any major database, not PostgreSQL specific. I feel that, when I'm reading PostgreSQL docs I would like to know how to set up multi-master replication with PostgreSQL not an explanation what a multi-master replication is. It's not about the actual documentation content, but rather on accents distribution. Now it is something like: These are the types of replication solutions possible, some of them can be done with PostgreSQL, I think it should be rather: With PostgreSQL and some third-party tools you can achieve such and such replication solutions, oh and by the way, research is done on such and such replication method, but it's not a production quality yet. And I try to think as my DBA-mates would do if they read the documentation, I'm not sure they would end up enlighted after reading the docs -- thay would probably say: hey, I knew that, it's well structured there, but I still don't know what should I use, or maybe where can I read something about this slony thing anyway?. Well, the idea is to have a web site that lists all the solutions that can be updated regularly, perhaps using the categories from the documentation. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] [HACKERS] Replication documentation addition
On Wed, Oct 25, 2006 at 04:42:17PM -0400, Bruce Momjian wrote: Dawid Kuroczko wrote: Bruce, I've read Your documentation and I was left a bit with a feeling that it's a bit too generic. It's almost as if it could be about just about any major database, not PostgreSQL specific. I feel that, when I'm reading PostgreSQL docs I would like to know how to set up multi-master replication with PostgreSQL not an explanation what a multi-master replication is. It's not about the actual documentation content, but rather on accents distribution. Now it is something like: These are the types of replication solutions possible, some of them can be done with PostgreSQL, I think it should be rather: With PostgreSQL and some third-party tools you can achieve such and such replication solutions, oh and by the way, research is done on such and such replication method, but it's not a production quality yet. And I try to think as my DBA-mates would do if they read the documentation, I'm not sure they would end up enlighted after reading the docs -- thay would probably say: hey, I knew that, it's well structured there, but I still don't know what should I use, or maybe where can I read something about this slony thing anyway?. Well, the idea is to have a web site that lists all the solutions that can be updated regularly, perhaps using the categories from the documentation. And the docs should point to that page, prominently (presumably that will happen after the page actually exists). Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
Jim C. Nasby wrote: Something else worth doing though is to have a paragraph explaining why there's no built-in replication. I don't have time to write something right now, but I can do it later tonight if no one beats me to it. I thought that was implied in the early paragraph about why there are many solutions. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
Joshua D. Drake wrote: Cesar Suga wrote: Hi, I also wrote Bruce about that. It happens that, if you 'freely advertise' commercial solutions (rather than they doing so by other vehicles) you will always happen to be an 'updater' to the docs if they change their product lines, if they change their business model, if and if. That is no different than the open source offerings. We have had several open source offerings that have died over the years. Replicator, for example has always been Replicator and has been around longer than any of the current replication solutions. The documentation comes with the open source tarball. I would welcome if the docs point to an unofficial wiki (maintained externally from authoritative PostgreSQL developers) or a website listing them and giving a brief of each solution. postgresql.org already does this for events (commercial training!) and news. Point to postgresql.org/download/commercial as there *already* are brief descriptions, pricing and website links. If you cite a commercial solution, as a fair game you should cite *all* of them. No. That doesn't make any sense either. I assume we aren't going to list all PostgreSQL OSS replication solutions (there are at least a dozen or more). You list the ones that are stable in their existence (commercial or not). And how would you determine it? Years of existance? Contribution to PostgreSQL's source code? It is not easy and wouldn't be fair. There are ones that certainly will be listed, and other doubtful ones (which would perhaps complain, that's why I said 'all' - if they are not stable, either they stay out of the market or fix their problems). If one enterprise has the right to be listed in the documentation, all of them might, as you will never be favouring one of them. You are looking at this the wrong way. This isn't about *any* enterprise. It is about a PostgreSQL Solution. There happens to be two or three known working open source solutions, and two or three known working commercial solutions. (see first three paragraphs) That's the main motivation to write this. Moreover, if there are also commercial solutions for high-end installs and they are cited as providers to those solutions, it (to a point) disencourages those of gathering themselves and writing open source extensions to PostgreSQL. No it doesn't. Because there is always the, It want's to be free! crowd. Yes, I agree there are. But also development in *that* cutting-edge is scarce. It feels that something had filled the gap if you list some commercial solution, mainly people in the trenches (DBAs). They would, obviously, firstly seek the commercial solutions as they are interested. So they click 'commercial products' in the main website. If people (who read the documentation) professionally work with PostgreSQL, they may already have been briefed by those commercial offerings in some way. Maybe, maybe not. Sincerely, Joshua D. Drake And I agree with your point, still. However, that would open a precedent for people to have to maintain lists of stable software in every documentation area. Regards, Cesar ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] [HACKERS] Replication documentation addition
Looking at that, I'm a) missing PgCluster and b) arguing that we have to admit that we simply can not 'list .. replication solutions ... and how to get them' because all of the solutions mentioned need quite some knowledge and require a more or less complex installation and configuration. There is also the question if we should have a sub section: Closed Source replication solutions: Mammoth Replicator Continuent P/Cluster ExtenDB Greenplum MPP (although this is kind of horizontal partitioning) Joshua D. Drake Regards Markus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 2006-10-24 at 12:34 -0700, Joshua D. Drake wrote: Looking at that, I'm a) missing PgCluster and b) arguing that we have to admit that we simply can not 'list .. replication solutions ... and how to get them' because all of the solutions mentioned need quite some knowledge and require a more or less complex installation and configuration. There is also the question if we should have a sub section: Closed Source replication solutions: Mammoth Replicator Continuent P/Cluster ExtenDB Greenplum MPP (although this is kind of horizontal partitioning) Where do you draw the line? You maybe surprised about what other options that includes. I'm happy to include a whole range of things, but please be very careful and precise about what you wish for. There's enough good solutions for open source PostgreSQL that it is easy and straightforward to limit it to just that. New contributions welcome, of course. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
Simon Riggs wrote: On Tue, 2006-10-24 at 12:34 -0700, Joshua D. Drake wrote: Looking at that, I'm a) missing PgCluster and b) arguing that we have to admit that we simply can not 'list .. replication solutions ... and how to get them' because all of the solutions mentioned need quite some knowledge and require a more or less complex installation and configuration. There is also the question if we should have a sub section: Closed Source replication solutions: Mammoth Replicator Continuent P/Cluster ExtenDB Greenplum MPP (although this is kind of horizontal partitioning) Where do you draw the line? Well that is certainly a good question but we do include links to some of the more prominent closed source software on the website as well. You maybe surprised about what other options that includes. I'm happy to include a whole range of things, but please be very careful and precise about what you wish for. If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling doesn't go in). Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling doesn't go in). ...and how do you define PostgreSQL exactly? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(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] Replication documentation addition
Simon Riggs wrote: On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling doesn't go in). ...and how do you define PostgreSQL exactly? I replication product or software defined to work with only PostgreSQL? I know there are some other products out there that will work from one db to another, but I am not sure if those would be considered HA solutions or migration solutions (which we could certainly document). Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 2006-10-24 at 15:33 -0700, Joshua D. Drake wrote: Simon Riggs wrote: On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling doesn't go in). ...and how do you define PostgreSQL exactly? I replication product or software defined to work with only PostgreSQL? (again)... how do you define PostgreSQL exactly? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Replication documentation addition
Simon Riggs wrote: On Tue, 2006-10-24 at 15:33 -0700, Joshua D. Drake wrote: Simon Riggs wrote: On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling doesn't go in). ...and how do you define PostgreSQL exactly? I replication product or software defined to work with only PostgreSQL? (again)... how do you define PostgreSQL exactly? What about PostgreSQL is unclear? Is your question do I consider EnterpriseDB, PostgreSQL? I have no comment on that matter. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(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] Replication documentation addition
On Tue, Oct 24, 2006 at 03:33:03PM -0700, Joshua D. Drake wrote: Simon Riggs wrote: On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling doesn't go in). ...and how do you define PostgreSQL exactly? I replication product or software defined to work with only PostgreSQL? AFAIK Continuent's product fails that test... I don't see any reason to exclude things that work with databases other than PostgreSQL, though I agree that replication that's actually in the application space (ie: it ties you to TomCat or some other platform) probably doesn't belong. My feeling is that people reading this chapter are looking for solutions and probably don't care as much about how exactly the solution works so long as it meets their needs. I know there are some other products out there that will work from one db to another, but I am not sure if those would be considered HA solutions or migration solutions (which we could certainly document). -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Jim C. Nasby wrote: On Tue, Oct 24, 2006 at 03:33:03PM -0700, Joshua D. Drake wrote: Simon Riggs wrote: On Tue, 2006-10-24 at 15:13 -0700, Joshua D. Drake wrote: If it were me, I would say that the replication option has to be specific to PostgreSQL (e.g; cjdbc or synchronous jakarta pooling doesn't go in). ...and how do you define PostgreSQL exactly? I replication product or software defined to work with only PostgreSQL? AFAIK Continuent's product fails that test... To my knowledge, p/cluster only works with PostgreSQL but I could be wrong. I don't see any reason to exclude things that work with databases other than PostgreSQL, though I agree that replication that's actually in the application space (ie: it ties you to TomCat or some other platform) probably doesn't belong. I was just trying to have a defined criteria of some sort. We could fill up pages and pages of possible replication solutions :) Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [DOCS] [HACKERS] Replication documentation addition
On Tue, 24 Oct 2006, Joshua D. Drake wrote: AFAIK Continuent's product fails that test... To my knowledge, p/cluster only works with PostgreSQL but I could be wrong. p/cluster was the old name for the PostgreSQL specific version. It's been rebranded as uni/cluster and they have versions for both PostgreSQL and MySQL. One of my customers is trying it out currently. -- Jeff Frost, Owner [EMAIL PROTECTED] Frost Consulting, LLC http://www.frostconsultingllc.com/ Phone: 650-780-7908 FAX: 650-649-1954 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Replication documentation addition
Joshua D. Drake wrote: Looking at that, I'm a) missing PgCluster and b) arguing that we have to admit that we simply can not 'list .. replication solutions ... and how to get them' because all of the solutions mentioned need quite some knowledge and require a more or less complex installation and configuration. There is also the question if we should have a sub section: Closed Source replication solutions: Mammoth Replicator Continuent P/Cluster ExtenDB Greenplum MPP (although this is kind of horizontal partitioning) I vote no. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Replication documentation addition
Joshua D. Drake wrote: Josh Berkus wrote: Bruce, I have updated the text. Please let me know what else I should change. I am unsure if I should be mentioning commercial PostgreSQL products in our documentation. I think you should mention the postgresql-only ones, but just briefly with a link. Bizgres MPP, ExtenDB, uni/cluster, and Mammoth Replicator. And to further this I would expect that it would be a subsection.. e.g; a sect2 or sect3. I think the open source version should absolutely get top billing though. I am not inclined to add commercial offerings. If people wanted commercial database offerings, they can get them from companies that advertize. People are coming to PostgreSQL for open source solutions, and I think mentioning commercial ones doesn't make sense. If we are to add them, I need to hear that from people who haven't worked in PostgreSQL commerical replication companies. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] [HACKERS] Replication documentation addition
On Oct 24, 2006, at 8:48 PM, Bruce Momjian wrote: Joshua D. Drake wrote: Josh Berkus wrote: Bruce, I have updated the text. Please let me know what else I should change. I am unsure if I should be mentioning commercial PostgreSQL products in our documentation. I think you should mention the postgresql-only ones, but just briefly with a link. Bizgres MPP, ExtenDB, uni/cluster, and Mammoth Replicator. And to further this I would expect that it would be a subsection.. e.g; a sect2 or sect3. I think the open source version should absolutely get top billing though. I am not inclined to add commercial offerings. If people wanted commercial database offerings, they can get them from companies that advertize. People are coming to PostgreSQL for open source solutions, and I think mentioning commercial ones doesn't make sense. If we are to add them, I need to hear that from people who haven't worked in PostgreSQL commerical replication companies. I'm not coming to PostgreSQL for open source solutions. I'm coming to PostgreSQL for _good_ solutions. I want to see what solutions might be available for a problem I have. I certainly want to know whether they're freely available, commercial or some flavour of open source, but I'd like to know about all of them. A big part of the value of Postgresql is the applications and extensions that support it. Hiding the existence of some subset of those just because of the way they're licensed is both underselling postgresql and doing something of a disservice to the user of the document. Cheers, Steve ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] [HACKERS] Replication documentation addition
Steve Atkins wrote: If we are to add them, I need to hear that from people who haven't worked in PostgreSQL commerical replication companies. I'm not coming to PostgreSQL for open source solutions. I'm coming to PostgreSQL for _good_ solutions. I want to see what solutions might be available for a problem I have. I certainly want to know whether they're freely available, commercial or some flavour of open source, but I'd like to know about all of them. A big part of the value of Postgresql is the applications and extensions that support it. Hiding the existence of some subset of those just because of the way they're licensed is both underselling postgresql and doing something of a disservice to the user of the document. OK, does that mean we mention EnterpriseDB in the section about Oracle functions? Why not mention MS SQL if they have a better solution? I just don't see where that line can clearly be drawn on what to include. Do we mention Netiza, which is loosely based on PostgreSQL? It just seems very arbitrary to include commercial software. If someone wants to put in on a wiki, I think that would be fine because that doesn't seems as official. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Replication documentation addition
On Oct 24, 2006, at 9:20 PM, Bruce Momjian wrote: Steve Atkins wrote: If we are to add them, I need to hear that from people who haven't worked in PostgreSQL commerical replication companies. I'm not coming to PostgreSQL for open source solutions. I'm coming to PostgreSQL for _good_ solutions. I want to see what solutions might be available for a problem I have. I certainly want to know whether they're freely available, commercial or some flavour of open source, but I'd like to know about all of them. A big part of the value of Postgresql is the applications and extensions that support it. Hiding the existence of some subset of those just because of the way they're licensed is both underselling postgresql and doing something of a disservice to the user of the document. OK, does that mean we mention EnterpriseDB in the section about Oracle functions? Why not mention MS SQL if they have a better solution? I just don't see where that line can clearly be drawn on what to include. Do we mention Netiza, which is loosely based on PostgreSQL? It just seems very arbitrary to include commercial software. If someone wants to put in on a wiki, I think that would be fine because that doesn't seems as official. Good question. The line needs to be drawn somewhere. It's basically your judgement, tempered by other peoples feedback, though. If it were me, I'd ask myself Would I mention this product if it were open source? Would mentioning it help people using the document?. Cheers, Steve ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
