Re: [GENERAL] Slightly OT.
[EMAIL PROTECTED] wrote: Group, I have to admit, I'm a little disappointed. I'm a HUGE advocate of PostgreSQL(to state for the record) - in fact I always keep my eyes peeled for opportunities to recommend it in my day to day business. So why am I disappointed, and who really cares? I'm disappointed because SLONY-II has not been released yet to support multi-master replication! PostgreSQL is going through all of the releases - and that's great - BUT, where is the sync-up with the powerhouse of a component, that Slony-II would bring to the table? Slony-I is pretty sweet, but if Slony-II would release, I can imagine that this would introduce some major competition in the enterprise world against the commercial dyno's. Which databases ship with multi-master replication? 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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: [GENERAL] Slightly OT.
On Fri, 1 Jun 2007, Joshua D. Drake wrote: [EMAIL PROTECTED] wrote: Group, I have to admit, I'm a little disappointed. I'm a HUGE advocate of PostgreSQL(to state for the record) - in fact I always keep my eyes peeled for opportunities to recommend it in my day to day business. So why am I disappointed, and who really cares? I'm disappointed because SLONY-II has not been released yet to support multi-master replication! PostgreSQL is going through all of the releases - and that's great - BUT, where is the sync-up with the powerhouse of a component, that Slony-II would bring to the table? Slony-I is pretty sweet, but if Slony-II would release, I can imagine that this would introduce some major competition in the enterprise world against the commercial dyno's. Which databases ship with multi-master replication? I dunno, which ones? Which ones have robust and fully functional multi-master replication? (Oracle, MS SQL, not-PostgreSQL). Joshua D. Drake -- Louis Gonzales [EMAIL PROTECTED] http://www.linuxlouis.net ---(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: [GENERAL] Slightly OT.
[EMAIL PROTECTED] wrote: On Fri, 1 Jun 2007, Joshua D. Drake wrote: Which databases ship with multi-master replication? I dunno, which ones? Which ones have robust and fully functional multi-master replication? (Oracle, MS SQL, not-PostgreSQL). You consider Oracle RAC fully functional multi-master? You do realize that Oracle is the second largest software company in the world right? With Microsoft being number 1? Tell ya what, write me a check, we will get right on it ;0 Joshua D. Drake 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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: [GENERAL] Slightly OT.
On 6/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I'm disappointed because SLONY-II has not been released yet to support multi-master replication! I wouldn't pin all my hopes on a project still under development. (For me, personally, add the fact that Slony-I still has not solved single-master replication in a way that doesn't burden the developer/DBA with lots of unnecessary extra maintenance; I am not counting on its developers to fix this issue in Slony-II.) In the meantime, Cybertec (http://www.postgresql.at/, an Austrian company) just announced a commercial synchronous multimaster replication product based on 2-phase commit. It's expensive, and I can't speak for its maturity, and it may or may not scale as well as the projected Slony-II design, but the setup seems dead simple, and from the docs I have found it seems to transparently replicate schema changes, unlike Slony-I. So that's something. Alexander. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Slightly OT.
Alexander Staubo wrote: On 6/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I'm disappointed because SLONY-II has not been released yet to support multi-master replication! I wouldn't pin all my hopes on a project still under development. (For me, personally, add the fact that Slony-I still has not solved single-master replication in a way that doesn't burden the developer/DBA with lots of unnecessary extra maintenance; I am not counting on its developers to fix this issue in Slony-II.) In the meantime, Cybertec (http://www.postgresql.at/, an Austrian company) just announced a commercial synchronous multimaster replication product based on 2-phase commit. It's expensive, and I can't speak for its maturity, and it may or may not scale as well as the projected Slony-II design, but the setup seems dead simple, and from the docs I have found it seems to transparently replicate schema changes, unlike Slony-I. So that's something. I could be completely cranked but I believe that product is based on PgCluster which is horrendously slow. To be fair, it is still under heavy development and does show promise. Joshua D. Drake Alexander. ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Slightly OT.
On 6/1/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: > In the meantime, Cybertec (http://www.postgresql.at/, an Austrian > company) just announced a commercial synchronous multimaster > replication product based on 2-phase commit. It's expensive, and I [snip] I could be completely cranked but I believe that product is based on PgCluster which is horrendously slow. Well, dang, that's disappointing. Last I checked, the PGCluster design was fundamentally unscalable. Alexander. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Slightly OT.
Alexander Staubo wrote: > On 6/1/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: >> > In the meantime, Cybertec (http://www.postgresql.at/, an Austrian >> > company) just announced a commercial synchronous multimaster >> > replication product based on 2-phase commit. It's expensive, and I > [snip] >> I could be completely cranked but I believe that product is based on >> PgCluster which is horrendously slow. > > Well, dang, that's disappointing. Last I checked, the PGCluster design > was fundamentally unscalable. Multimaster replication generally is - thats why Slony-2 will almost certainly never exist in the form that it was originally imagined. Although I'm not (and never have been) an Oracle user, I've heard that RAC has it's own issues in this area as well. Regards, Dave ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Slightly OT.
Dave Page wrote: Alexander Staubo wrote: On 6/1/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: In the meantime, Cybertec (http://www.postgresql.at/, an Austrian company) just announced a commercial synchronous multimaster replication product based on 2-phase commit. It's expensive, and I [snip] I could be completely cranked but I believe that product is based on PgCluster which is horrendously slow. Well, dang, that's disappointing. Last I checked, the PGCluster design was fundamentally unscalable. Multimaster replication generally is - thats why Slony-2 will almost certainly never exist in the form that it was originally imagined. Although I'm not (and never have been) an Oracle user, I've heard that RAC has it's own issues in this area as well. IMO, the future is application partitioning, not multi-master. Also, what I find interesting here is that PostgreSQL on modest hardware does excessively well. I have a client right now that is running an 8 core, 16 gig box with only 14 spindles. They are processing 6ktps and it takes 14 tomcat servers to bring the database down. Any multi-master solution is going to fall over well before 6ktps. Sincerely, Joshua D. Drake P.S. I should note that we are working toward more than 6ktps and will report back ;) Regards, Dave -- === 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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: [GENERAL] Slightly OT.
It does so well because it KICKS ICE! On Fri, 1 Jun 2007, Joshua D. Drake wrote: Dave Page wrote: Alexander Staubo wrote: On 6/1/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: In the meantime, Cybertec (http://www.postgresql.at/, an Austrian company) just announced a commercial synchronous multimaster replication product based on 2-phase commit. It's expensive, and I [snip] I could be completely cranked but I believe that product is based on PgCluster which is horrendously slow. Well, dang, that's disappointing. Last I checked, the PGCluster design was fundamentally unscalable. Multimaster replication generally is - thats why Slony-2 will almost certainly never exist in the form that it was originally imagined. Although I'm not (and never have been) an Oracle user, I've heard that RAC has it's own issues in this area as well. IMO, the future is application partitioning, not multi-master. Also, what I find interesting here is that PostgreSQL on modest hardware does excessively well. I have a client right now that is running an 8 core, 16 gig box with only 14 spindles. They are processing 6ktps and it takes 14 tomcat servers to bring the database down. Any multi-master solution is going to fall over well before 6ktps. Sincerely, Joshua D. Drake P.S. I should note that we are working toward more than 6ktps and will report back ;) Regards, Dave -- Louis Gonzales [EMAIL PROTECTED] http://www.linuxlouis.net ---(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: [GENERAL] Slightly OT.
On Fri, 2007-06-01 at 17:00 +0200, Alexander Staubo wrote: > the projected Slony-II design, but the setup seems dead simple, and > from the docs I have found it seems to transparently replicate schema > changes, unlike Slony-I. So that's something. > To be fair to Slony-I, the fact that it does not replicate DDL is a feature, not a bug. It's table-based, which is a very flexible design. Regards, Jeff Davis ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Slightly OT.
On 6/1/07, Jeff Davis <[EMAIL PROTECTED]> wrote: On Fri, 2007-06-01 at 17:00 +0200, Alexander Staubo wrote: > the projected Slony-II design, but the setup seems dead simple, and > from the docs I have found it seems to transparently replicate schema > changes, unlike Slony-I. So that's something. To be fair to Slony-I, the fact that it does not replicate DDL is a feature, not a bug. It's table-based, which is a very flexible design. I fail to see how that's an excuse not to replicate DDL. If I run "alter table" on the master, there is no reason whatever that this command cannot be executed on all the slaves -- which is what I would expect of a replication system. To put it differently: A slave's table is a replica of the master's table; if I alter the master table, and the slave is not updated to reflect this change, then the slave table is no longer a true replica, and the system has failed its core purpose, that of *replicating*. I could be wrong, but I believe Slony fails at this because it is trigger-based and simply cannot detect DDL changes. Alexander. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Slightly OT.
Alexander Staubo wrote: On 6/1/07, Jeff Davis <[EMAIL PROTECTED]> wrote: On Fri, 2007-06-01 at 17:00 +0200, Alexander Staubo wrote: > the projected Slony-II design, but the setup seems dead simple, and > from the docs I have found it seems to transparently replicate schema > changes, unlike Slony-I. So that's something. To be fair to Slony-I, the fact that it does not replicate DDL is a feature, not a bug. It's table-based, which is a very flexible design. I fail to see how that's an excuse not to replicate DDL. If I run "alter table" on the master, there is no reason whatever that this command cannot be executed on all the slaves -- which is what I would expect of a replication system. As the owner of a company that actually actively developing a replication system and has for years... I suggest you start putting your code where your words are. This is not nearly as simple as it seems. There is a reason that Slony attempts to do it in user space instead of postgresql space. Joshua D. Drake To put it differently: A slave's table is a replica of the master's table; if I alter the master table, and the slave is not updated to reflect this change, then the slave table is no longer a true replica, and the system has failed its core purpose, that of *replicating*. I could be wrong, but I believe Slony fails at this because it is trigger-based and simply cannot detect DDL changes. Alexander. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Slightly OT.
On Fri, Jun 01, 2007 at 08:57:36PM +0200, Alexander Staubo wrote: > I fail to see how that's an excuse not to replicate DDL. If I run > "alter table" on the master, there is no reason whatever that this > command cannot be executed on all the slaves -- which is what I would > expect of a replication system. There is a way to replicate the DDL. A well-documented way. It's sort of ugly, I think everyone will admit, but it was the path chosen because it allowed the entire thing to fit in user space, which meant it was possible to install it on an unpatched PostgreSQL that was already deployed in the field. That's a non-zero benefit. > I could be wrong, but I believe Slony fails at this because it is > trigger-based and simply cannot detect DDL changes. No, there were in fact alternatives (like, for instance, patching the back end code). But that was undesirable for the reason I note above. A -- Andrew Sullivan | [EMAIL PROTECTED] In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Slightly OT.
"Alexander Staubo" <[EMAIL PROTECTED]> writes: > On 6/1/07, Jeff Davis <[EMAIL PROTECTED]> wrote: >> To be fair to Slony-I, the fact that it does not replicate DDL is a >> feature, not a bug. It's table-based, which is a very flexible design. > I fail to see how that's an excuse not to replicate DDL. > I could be wrong, but I believe Slony fails at this because it is > trigger-based and simply cannot detect DDL changes. You are wrong. The Slony guys say this is intentional, and they have some good arguments. They may be making a virtue of necessity, but automatic replication of DDL is not nearly as open-and-shut a decision as you paint it. 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: [GENERAL] Slightly OT.
[EMAIL PROTECTED] writes: > I'm disappointed because SLONY-II has not been released yet to support > multi-master replication! PostgreSQL is going through all of the > releases - and that's great - BUT, where is the sync-up with the > powerhouse of a component, that Slony-II would bring to the table? > Slony-I is pretty sweet, but if Slony-II would release, I can imagine > that this would introduce some major competition in the enterprise > world against the commercial dyno's. There is some effort still going into Postgres-R from a research perspective, but as far as I know, nobody has been working on Slony-II for well over a year now. Unfortunately, a combination of factors went together to make it "not workable." - Spread licensing was something of an issue; - Spread scalability caused quite a few issues (it's apparently tough to make it stable when using it under HEAVY load); - There was a token passing bottleneck in Spread limiting its performance; - New application failure scenarios emerged that wouldn't have take place in non-MM systems. The issues built to the point of making it unworthwhile to continue development effort :-(. If someone completed a suitable reimplementation of the wheel on GCS, and produced something more usable for the purpose, such as the (theorized) Anasazi system, it might be worth proceeding again. http://www.lethargy.org/~jesus/archives/53-Lets-reimplement-the-wheel...-or-at-least-another-GCS..html But it's fair to say that reality did not live up to the early hopes. Supposing we came up with a Wicked Better GCS, that might merely allow efforts to get a bit further, and then hang up on something else. Don't hold your breath expecting Slony-II to be around any corners... -- let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;; http://linuxfinances.info/info/sap.html "It seems certain that much of the success of Unix follows from the readability, modifiability, and portability of its software." -- Dennis M. Ritchie, September, 1979 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Slightly OT.
On 6/1/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: As the owner of a company that actually actively developing a replication system and has for years... I suggest you start putting your code where your words are. That doesn't make any sense. As a database *user* it's my prerogative to criticize the bits that make my life painful. Intentional or not, the Slony design compromises its user-friendliness. I would love for the answer to have been "sorry, we did not have time or manpower enough to implement fully transparent replication yet, because it's a rather complex, you see"; but it's not, and I balk at the idea that you cannot strive for something better. For example, there is clearly an opportunity to implement the appropriate hooks in PostgreSQL that can be used *if they are available*; otherwise, on unpatched/older systems, require the use of the slonik command. Alexander. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Slightly OT.
On 6/1/07, Andrew Sullivan <[EMAIL PROTECTED]> wrote: > I could be wrong, but I believe Slony fails at this because it is > trigger-based and simply cannot detect DDL changes. No, there were in fact alternatives (like, for instance, patching the back end code). But that was undesirable for the reason I note above. Curiously enough, that does not conflict with anything I wrote. I am, clearly, not wrong: A deliberate decision was made not to patch PostgreSQL with the hooks Slony would need to support DDL changes; therefore, since it relies purely on triggers, it cannot detect DDL changes. Alexander. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Slightly OT.
On Fri, Jun 01, 2007 at 11:08:50PM +0200, Alexander Staubo wrote: > That doesn't make any sense. As a database *user* it's my prerogative > to criticize the bits that make my life painful. Sure. And as a user of free software, it is your prerogative to propose a way that the software can be modified to make it do what you want, and to do the work to so modify it. Does this mean you are offering? > For example, there is clearly an opportunity to implement the > appropriate hooks in PostgreSQL that can be used *if they are > available*; otherwise, on unpatched/older systems, require the use of > the slonik command. I don't know that that is clear at all. To begin with, one would have to get agreement on what those hooks would be. If you look on the pgfoundry site, you'll note that I set up a project there to try to get such a list of hooks defined. It went nowhere: everyone who was working on replication said it was premature and impossible to do this in advance and such like. Moreover, what you are suggesting is a _massive_ increase in the complications of the code, because it suggests to me that you want DDL to happen as easily as it does in single-node cases. But it's not that easy, which is another part of the reason DDL is handled specially. If you don't know what the hard parts are, I suggest you go and read the rather detailed original concept document that Jan put together for the community prior to starting work on the system. But just as a teaser: what do you do if your DDL on the local node has succeeded, and you added additional data in the same transaction, but the DDL fails for some reason on a remote node? Note that this one isn't even one of the actually tricky cases. A -- Andrew Sullivan | [EMAIL PROTECTED] A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton ---(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: [GENERAL] Slightly OT.
"Alexander Staubo" <[EMAIL PROTECTED]> writes: > I would love for the answer to have been "sorry, we did not have time > or manpower enough to implement fully transparent replication yet, > because it's a rather complex, you see"; Would you still love that if you're one of the people who use replication to move the data to a reporting database which has a modified schema appropriate for the different usage? This improvement would make it useless for that purpose. -- Gregory Stark 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: [GENERAL] Slightly OT.
On 6/2/07, Gregory Stark <[EMAIL PROTECTED]> wrote: "Alexander Staubo" <[EMAIL PROTECTED]> writes: > I would love for the answer to have been "sorry, we did not have time > or manpower enough to implement fully transparent replication yet, > because it's a rather complex, you see"; Would you still love that if you're one of the people who use replication to move the data to a reporting database which has a modified schema appropriate for the different usage? This improvement would make it useless for that purpose. All you would require is a simple boolean flag to enable or disable automatic DDL propagation, surely. Clearly people use replication for different purposes; the current system favours people who prefer to handle DDL propagation manually, and I am not one of them. Alexander. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Slightly OT.
>>> ...fully transparent replication... >> >> There is no such thing. Asking for it implies ignorance of the issues >> involved and what is actually available with other database products. >> > > We are darn close ;) Argh, to be clear: I was referring to multimaster. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Slightly OT.
Scott Ribe wrote: ...fully transparent replication... There is no such thing. Asking for it implies ignorance of the issues involved and what is actually available with other database products. We are darn close ;) Argh, to be clear: I was referring to multimaster. Heh, that isn't even on our roadmap. It is a waste of energies imo. 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Slightly OT.
On 6/1/07, Andrew Sullivan <[EMAIL PROTECTED]> wrote: On Fri, Jun 01, 2007 at 11:08:50PM +0200, Alexander Staubo wrote: > That doesn't make any sense. As a database *user* it's my prerogative > to criticize the bits that make my life painful. Sure. And as a user of free software, it is your prerogative to propose a way that the software can be modified to make it do what you want, and to do the work to so modify it. Does this mean you are offering? It's my prerogative, but not my moral obligation. I have no intention of becoming a Slony developer. I use Slony because I have no choice, and I would not have touched it with a bargepole if I did not need to. (I do contribute to projects that I do enjoy using.) On the other hand, if my current project goes well, I hope that I will be able to persuade my partners to set aside some cash to fund improvements to PostgreSQL and/or Slony. > For example, there is clearly an opportunity to implement the > appropriate hooks in PostgreSQL that can be used *if they are > available*; otherwise, on unpatched/older systems, require the use of > the slonik command. I don't know that that is clear at all. [snip] Perhaps not, but all I wrote was there is an *opportunity*, technical complexities aside, in an effort to provide *constructive* criticism. I said this based on your previous comment, that "the path [was] chosen because it allowed the entire thing to fit in user space, which meant it was possible to install it on an unpatched PostgreSQL", which implies that patching PostgreSQL is a possibility that may be considered. To begin with, one would have to get agreement on what those hooks would be. If you look on the pgfoundry site, you'll note that I set up a project there to try to get such a list of hooks defined. It went nowhere: [snip] For the record, I really appreciate the effort you made. I wasn't paying attention to pgsql-hackers at the time, so I missed the somewhat depressing discussion you had with Markus Schiltknecht. Moreover, what you are suggesting is a _massive_ increase in the complications of the code That, incidentally, is the kind of thing I want to hear, as opposed to "you are wrong", which is neither helpful nor polite. [snip] the reason DDL is handled specially. If you don't know what the hard parts are, I suggest you go and read the rather detailed original concept document that Jan put together for the community prior to starting work on the system. But just as a teaser: what do you do if your DDL on the local node has succeeded, and you added additional data in the same transaction, but the DDL fails for some reason on a remote node? Note that this one isn't even one of the actually tricky cases. Could you not (I ask naively) detect the first DDL statement is submitted in a transaction on the master, then start a transaction on each slave, then funnel this and all subsequent statements synchronously to every nodes, then prepare and commit everyone? Mind you, I profess virtual ignorance of the numerous border cases involved, so do go ahead and tell me how wrong I am and how silly I am for suggesting I could have the balls to even consider suggesting something like this. :) This suggestion implies transparent DDL replication would be synchronous, which seems like a decent compromise when you can ensure that all nodes are committed atomically, and virtually guaranteed to do so. That would be an improvement on the current behaviour (section 15 of the Slony manual): "If there is anything broken about the script, or about how it executes on a particular node, this will cause the slon daemon for that node to panic and crash" Alexander. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Slightly OT.
On Sat, Jun 02, 2007 at 12:05:20AM +0200, Alexander Staubo wrote: > All you would require is a simple boolean flag to enable or disable > automatic DDL propagation, surely. You know, it is just possible that some of the responses you are getting in this thread have to do with the glib way you say "just a simple flag", waving away all the corner cases and difficult parts. What do you do, for instance, when your automatic DDL wedges the replication system after data-replicating events have come in? What do you do when there happens to be a schema mismatch that you didn't know about? (How do you even detect such a thing?) That isn't a SMOP: it requires design that is not trivial, and you don't seem to be spending any time thinking about those issues before brushing off the current design as some sort of nasty thoughtless attempt to make your life more difficult on the part of those who have worked on the system. DDL changes require that every node have the new schema before any of the node-affecting data gets there. We have _enough_ problems with DDL failing on target systems without increasing this problem tenfold by doing it automatically. A -- Andrew Sullivan | [EMAIL PROTECTED] The whole tendency of modern prose is away from concreteness. --George Orwell ---(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: [GENERAL] Slightly OT.
On Sat, Jun 02, 2007 at 12:23:44AM +0200, Alexander Staubo wrote: > Could you not (I ask naively) detect the first DDL statement is > submitted in a transaction Maybe. > on the master, then start a transaction on > each slave, then funnel this and all subsequent statements > synchronously to every nodes, then prepare and commit everyone? You could if 2PC was ubiquitous, which is certainly wasn't when the code was designed (remember, it was originally compatible all the way back to 7.3). Some people suggested using 2PC "if it's there", but that just seems to me to be asking for really painful problems. It also entails that all DDL has to happen on every node at the same time, which imposes a bottleneck not actually currently in the system. It is probably the case, however, that version 2 of the system will break some of these backwards compatibility attempts in order to depend on some new back end features -- putting this entirely in user space turns out to be awful. It's how we got the monstrous catalog corruption hack. This is getting pretty Slony specific, though, so if we're to continue this thread, I suggest we do it on the Slony list. A -- Andrew Sullivan | [EMAIL PROTECTED] "The year's penultimate month" is not in truth a good way of saying November. --H.W. Fowler ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Slightly OT.
On Sat, 2007-06-02 at 00:05 +0200, Alexander Staubo wrote: > On 6/2/07, Gregory Stark <[EMAIL PROTECTED]> wrote: > > "Alexander Staubo" <[EMAIL PROTECTED]> writes: > > > > > I would love for the answer to have been "sorry, we did not have time > > > or manpower enough to implement fully transparent replication yet, > > > because it's a rather complex, you see"; > > > > Would you still love that if you're one of the people who use replication to > > move the data to a reporting database which has a modified schema > > appropriate > > for the different usage? This improvement would make it useless for that > > purpose. > > All you would require is a simple boolean flag to enable or disable > automatic DDL propagation, surely. Clearly people use replication for > different purposes; the current system favours people who prefer to > handle DDL propagation manually, and I am not one of them. > Here is some work going on that looks like what you want: http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php http://momjian.postgresql.org/cgi-bin/pgtodo?pitr You might also seriously consider PgPool-II. There are many, many approaches to replication, high-availability, and related topics. For almost any combination of log-based, query-based, trigger-based and synchronous, asynchronous and master/master, master/slave and shared storage, local storage -- there is some PG person working on it. They all have advantages and disadvantages. The one, specific type of replication that suits you is not necessarily what everyone else wants. Try to understand that some of these options are built around businesses out of *need* rather than want. Businesses *need* functionality and flexibility. Administrative simplicity and conveniences (like replicated DDL) are obviously not the only goals of something like Slony-I. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Slightly OT.
On 6/2/07, Andrew Sullivan <[EMAIL PROTECTED]> wrote: On Sat, Jun 02, 2007 at 12:05:20AM +0200, Alexander Staubo wrote: > All you would require is a simple boolean flag to enable or disable > automatic DDL propagation, surely. You know, it is just possible that some of the responses you are getting in this thread have to do with the glib way you say "just a simple flag", waving away all the corner cases and difficult parts. Or maybe I'm focused on the end-user experience and trying to mentally fit the technology to that idea rather than the other way around. Too much software is designed by developers, and too little software is designed for users. I don't mean to be glib at all -- the person was asking, in effect, "but this hypothetical feature X would break case Y", to which I suggested a flag to turn X on or off. PostgreSQL has plenty of flags that turn features on and off. Whether or not the hypothetical feature is hard to implement, or should be implemented, is an orthogonal concern. What do you do, for instance, when your automatic DDL wedges the replication system after data-replicating events have come in? There needs to be a point of synchronization when a DDL transaction appears that blocks further write transactions from running. As far as I can tell, the slaves themselves can continue to receive pending events, but perhaps not. As far as I can tell, table locking on the master ensures that concurrent, not-yet-committed transactions started *before* the DDL transaction will block the DDL itself, but I'm sure there's a gap here that could lead to craziness; it seems to me that you could detect it reliably and throw an error when it happens. I admit I am at a disadvantage here. I never intended to enter into a full-fledged discussion about implementation details, but you teased me, dammit. I clearly don't have enough knowledge about the way Slony works, but that does not disqualify me from suggesting that the current behaviour is unfriendly. Certainly there are technical and historic facts that explain this behaviour, but I see nothing wrong with challenging those notions in the name of helping the situation, at least according to my own aesthetics. Last I checked, nobody was actually terribly *happy* about having to pipe schema changes through slonik. Of course, as far as I can see (especially with regard to this thread), nobody seems to mind all that much, either, but then again people put up with a lot of crap before we had, say, sliced bread or psql tab completion. [...] before brushing off the current design as some sort of nasty thoughtless attempt to make your life more difficult on the part of those who have worked on the system. I'm not that paranoid. :) Alexander. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Slightly OT.
On 6/2/07, Jeff Davis <[EMAIL PROTECTED]> wrote: Here is some work going on that looks like what you want: http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php I had no idea someone was working on WAL-log-based replication; I saw the TODO entry a while ago, but I missed the thread. I think WAL replication is a beautiful idea, so I'll gladly throw my support behind this. Thanks for the pointer. You might also seriously consider PgPool-II. pgpool-II seems like a decent idea. I'm not sure if the partitioning can support referential integrity though -- would they have to be declared as CHECK constraints that used dblink()? Also, it doesn't seem capable of planning a query intelligently, which means that a query such as "select * from foo where id = 123" is going to be aggregated across all nodes even though only one node has the partition covering the id range [0, 1000], say. Alexander. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Slightly OT.
On Sat, 2007-06-02 at 01:44 +0200, Alexander Staubo wrote: > On 6/2/07, Jeff Davis <[EMAIL PROTECTED]> wrote: > > Here is some work going on that looks like what you want: > > > > http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php > > I had no idea someone was working on WAL-log-based replication; I saw > the TODO entry a while ago, but I missed the thread. I think WAL > replication is a beautiful idea, so I'll gladly throw my support > behind this. Thanks for the pointer. > I think that project would add some great functionality to postgres. > > You might also seriously consider PgPool-II. > > pgpool-II seems like a decent idea. I'm not sure if the partitioning > can support referential integrity though -- would they have to be > declared as CHECK constraints that used dblink()? You shouldn't use a volatile function in a check constraint. Use a trigger instead, but even that is unlikely to work for enforcing constraints correctly. In general, for partitioning, you have to make some sacrifices. It's very challenging (and/or expensive) to ensure uniqueness across partitions. > Also, it doesn't seem capable of planning a query intelligently, which > means that a query such as "select * from foo where id = 123" is going > to be aggregated across all nodes even though only one node has the > partition covering the id range [0, 1000], say. Take a closer look. There is quite a lot of intelligence in there. The query you mention will be rewritten to send simple WHERE clauses to the underlying partitions. That, combined with constraint exclusion (CE), will ensure that the only partitions scanned are those not excluded by the partition's predicate (i.e. it will only scan one partition if it's partitioned based on "id"). Actually, I'm not sure whether it relies on CE or not, but the point is that it won't scan all the partitions. Also, this means it could use an index scan on that underlying partition, which is crucial. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Slightly OT.
On Sat, Jun 02, 2007 at 01:30:53AM +0200, Alexander Staubo wrote: > There needs to be a point of synchronization when a DDL transaction > appears that blocks further write transactions from running. As far as > I can tell, the slaves themselves can continue to receive pending > events, but perhaps not. In order to do it automatically, you have to lock everyone, get all the events through, and then perform the DDL, and then come out of lock. Otherwise, what happens when you do DROP COLUMN? If it goes through ahead of data that ought to go into that column, you have just broken your cluster. I suppose you could figure out a way to work around this, but pretty soon you are building an artificial intelligence expert system with event-predicting capabilities. Such systems are not well known for their simplicity and ease of maintenance. > Last I checked, nobody was actually terribly *happy* about having to > pipe schema changes through slonik. Nobody would suggest it's the friendliest arrangement. But this is a field where the details really count, and therefore proposals to make it more friendly have to account for how that friendliness in a lot of cases doesn't lead to complete breakage in others. (I had to be exposed to the multimaster MS SQL stuff, years ago, and I have to say that it was great when it worked; but when things went south, boy did your life suck. Whether it is better now, I don't know.) A -- Andrew Sullivan | [EMAIL PROTECTED] Unfortunately reformatting the Internet is a little more painful than reformatting your hard drive when it gets out of whack. --Scott Morris ---(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
Partitioning (was Re: [GENERAL] Slightly OT.)
On 06/01/07 19:29, Jeff Davis wrote: [snip] You shouldn't use a volatile function in a check constraint. Use a trigger instead, but even that is unlikely to work for enforcing constraints correctly. In general, for partitioning, you have to make some sacrifices. It's very challenging (and/or expensive) to ensure uniqueness across partitions. Are partitioned databases the same as federated databases? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ---(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: Partitioning (was Re: [GENERAL] Slightly OT.)
On Fri, 2007-06-01 at 22:13 -0500, Ron Johnson wrote: > On 06/01/07 19:29, Jeff Davis wrote: > [snip] > > You shouldn't use a volatile function in a check constraint. Use a > > trigger instead, but even that is unlikely to work for enforcing > > constraints correctly. > > > > In general, for partitioning, you have to make some sacrifices. It's > > very challenging (and/or expensive) to ensure uniqueness across > > partitions. > > Are partitioned databases the same as federated databases? > I think that usually people refer to a table that is split to be partitioned (whether across servers or within a single server). I think federated databases are where various parts of the database are split across servers, but tables may be intact. That's my own understanding of the terminology. Regards, Jeff Davis ---(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: [GENERAL] [Slightly OT] data model books/resources?
In the last exciting episode, [EMAIL PROTECTED] ("Aaron Glenn") wrote:
> Anyone care to share the great books, articles, manifestos, notes,
> leaflets, etc on data modelling they've come across? Ideally I'd like
> to find a great college level book on data models, but I haven't come
> across one that even slightly holds "definitive resource"-type status.
>
> Feel free to reply off list to keep the clutter down - I'd be happy to
> summarize responses for the list.
Any web search involving the word "modelling" is likely to take you
down some wrong paths :-).
One interesting looking web site with a barrel of examples is
.
A problem with this is that it is common for your application
framework to, a priori, strongly affect the shape of the data model.
Thus, if you're building for Ruby on Rails, you'll be drawn into
models that are RoR-shaped. If you use a particular OO language,
there will probably be strong temptation to try to map directly onto
its object model, which will, again, heavily affect the shape of your
data models.
It seems likely that this factor (which might be simplified to "to one
with a hammer, everything looks like a nail, including your thumb")
will shape things almost moreso than the direct domain of the problem.
--
output = ("cbbrowne" "@" "gmail.com")
http://linuxdatabases.info/info/slony.html
Rules of the Evil Overlord #173. "Although it would provide amusement,
I will not confess to the hero's rival that I was the one who
committed the heinous act for which he blames the hero."
Re: [GENERAL] [Slightly OT] data model books/resources?
On Thursday 30 March 2006 03:03, Aaron Glenn wrote:
> Anyone care to share the great books, articles, manifestos, notes,
> leaflets, etc on data modelling they've come across? Ideally I'd like
> to find a great college level book on data models, but I haven't come
> across one that even slightly holds "definitive resource"-type status.
>
I've heard that "Relational Database Design" (ISBN: 0123264251) is good for
college level introductory material, though the book I generally recommend
most is "Practical Issues in Database Management" (ISBN: 0201485559)
> Feel free to reply off list to keep the clutter down - I'd be happy to
> summarize responses for the list.
>
We're all about clutter :-)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] [Slightly OT] data model books/resources?
Robert Treat wrote: On Thursday 30 March 2006 03:03, Aaron Glenn wrote: Anyone care to share the great books, articles, manifestos, notes, leaflets, etc on data modelling they've come across? Ideally I'd like to find a great college level book on data models, but I haven't come across one that even slightly holds "definitive resource"-type status. I've heard that "Relational Database Design" (ISBN: 0123264251) is good for college level introductory material, though the book I generally recommend most is "Practical Issues in Database Management" (ISBN: 0201485559) Feel free to reply off list to keep the clutter down - I'd be happy to summarize responses for the list. We're all about clutter :-) I also highly suggest: Database in Depth : Relational Theory for Practitioners (Paperback) by C.J. Date It is a great, pratical book that isn't a snore. 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/ ---(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: [GENERAL] [Slightly OT] data model books/resources?
On Mar 30, 2006, at 2:03 AM, Aaron Glenn wrote:Anyone care to share the great books, articles, manifestos, notes,leaflets, etc on data modelling they've come across? Ideally I'd liketo find a great college level book on data models, but I haven't comeacross one that even slightly holds "definitive resource"-type status.Feel free to reply off list to keep the clutter down - I'd be happy tosummarize responses for the list.Thanks,aaron.glennI've found Database Modeling Essentials by Simsion and Witt (ISBN: 0-12-644551-6) to be a good resource.--Thomas F. O'ConnellDatabase Architecture and ProgrammingCo-FounderSitening, LLChttp://www.sitening.com/3004 B Poston AvenueNashville, TN 37203-1314615-260-0005 (cell)615-469-5150 (office)615-469-5151 (fax)
Re: [GENERAL] [Slightly OT] data model books/resources?
On Thursday 30 March 2006 03:03, Aaron Glenn wrote: Anyone care to share the great books, articles, manifestos, notes, leaflets, etc on data modelling they've come across? Ideally I'd like to find a great college level book on data models, but I haven't come across one that even slightly holds "definitive resource"-type status. I've heard that "Relational Database Design" (ISBN: 0123264251) is good for college level introductory material, though the book I generally recommend most is "Practical Issues in Database Management" (ISBN: 0201485559) Feel free to reply off list to keep the clutter down - I'd be happy to summarize responses for the list. We're all about clutter :-) Well then, in that case, can I add to the clutter by asking a question about IT training? I was just asked today, by a vice president in the company I'm working with, to train one of his staff to become a database programmer and administrator. I have taught software engineering using UML, and programming in Java and C++. I have not taught database programming and administration, although I have done some of each for some of my own applications. My Question? Can the folk in this group help me develop a reading list and a list of competencies for this fellow to master? While I can easily develop a list of books dealing with databases in general and SQL in particular, it is not so easy to separate the wheat from the chaff, and I do not want to waste a pile of money on evaluating the range of books that are available. I'd therefore like accounts of books to avoid, and why, as well as books that are essential in any respectable collection, and why. I'm interested both in text books, with exercises, and reference books (both theoretical and practical). Thanks Ted ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] [Slightly OT] data model books/resources?
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Robert
Treat) transmitted:
> On Thursday 30 March 2006 03:03, Aaron Glenn wrote:
>> Anyone care to share the great books, articles, manifestos, notes,
>> leaflets, etc on data modelling they've come across? Ideally I'd like
>> to find a great college level book on data models, but I haven't come
>> across one that even slightly holds "definitive resource"-type status.
>
> I've heard that "Relational Database Design" (ISBN: 0123264251) is
> good for college level introductory material, though the book I
> generally recommend most is "Practical Issues in Database
> Management" (ISBN: 0201485559)
The one trouble with PIDM is somewhat like that of the discussion of
SQL in the "Third Manifest" book, namely that it's a lot better at
prescribing "Things Not To Do" than it is about how models *should* be
constructed.
With that caveat, it's on my desk :-).
--
output = reverse("moc.liamg" "@" "enworbbc")
http://linuxdatabases.info/info/spreadsheets.html
Rules of the Evil Overlord #216. "If my Legions of Terror are defeated
in a battle, I will quietly withdraw and regroup instead of launching
a haphazard mission to assassinate the hero."
Re: [GENERAL] [Slightly OT] data model books/resources?
On Apr 1, 2006, at 0:19 , Robert Treat wrote: On Thursday 30 March 2006 03:03, Aaron Glenn wrote: Anyone care to share the great books, articles, manifestos, notes, leaflets, etc on data modelling they've come across? Ideally I'd like to find a great college level book on data models, but I haven't come across one that even slightly holds "definitive resource"-type status. I've heard that "Relational Database Design" (ISBN: 0123264251) is good for college level introductory material, though the book I generally recommend most is "Practical Issues in Database Management" (ISBN: 0201485559) Might be a bit OT your OT (as it leans towards the relational model in general rather than data modeling--applying the relational model for a particular use), but I am really enjoying "Database in Depth : Relational Theory for Practitioners" (ISBN: 0596100124). Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
One last Slony question (was Re: [GENERAL] Slightly OT.)
On 06/01/07 17:31, Andrew Sullivan wrote: On Sat, Jun 02, 2007 at 12:23:44AM +0200, Alexander Staubo wrote: Could you not (I ask naively) detect the first DDL statement is submitted in a transaction Maybe. on the master, then start a transaction on each slave, then funnel this and all subsequent statements synchronously to every nodes, then prepare and commit everyone? You could if 2PC was ubiquitous, which is certainly wasn't when the code was designed (remember, it was originally compatible all the way back to 7.3). Some people suggested using 2PC "if it's there", but that just seems to me to be asking for really painful problems. It also entails that all DDL has to happen on every node at the same time, which imposes a bottleneck not actually currently in the system. Since DDL is infrequent, is that bottleneck an acceptable trade-off? It is probably the case, however, that version 2 of the system will break some of these backwards compatibility attempts in order to depend on some new back end features -- putting this entirely in user space turns out to be awful. It's how we got the monstrous catalog corruption hack. This is getting pretty Slony specific, though, so if we're to continue this thread, I suggest we do it on the Slony list. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: One last Slony question (was Re: [GENERAL] Slightly OT.)
Ron Johnson wrote: On 06/01/07 17:31, Andrew Sullivan wrote: On Sat, Jun 02, 2007 at 12:23:44AM +0200, Alexander Staubo wrote: Could you not (I ask naively) detect the first DDL statement is submitted in a transaction Maybe. on the master, then start a transaction on each slave, then funnel this and all subsequent statements synchronously to every nodes, then prepare and commit everyone? You could if 2PC was ubiquitous, which is certainly wasn't when the code was designed (remember, it was originally compatible all the way back to 7.3). Some people suggested using 2PC "if it's there", but that just seems to me to be asking for really painful problems. It also entails that all DDL has to happen on every node at the same time, which imposes a bottleneck not actually currently in the system. Since DDL is infrequent, is that bottleneck an acceptable trade-off? Define infrequent? I have customers that do it, everyday in prod. They do it willingly and refuse to change that habit. 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: One last Slony question (was Re: [GENERAL] Slightly OT.)
On 06/01/07 18:35, Joshua D. Drake wrote: Ron Johnson wrote: On 06/01/07 17:31, Andrew Sullivan wrote: On Sat, Jun 02, 2007 at 12:23:44AM +0200, Alexander Staubo wrote: Could you not (I ask naively) detect the first DDL statement is submitted in a transaction Maybe. on the master, then start a transaction on each slave, then funnel this and all subsequent statements synchronously to every nodes, then prepare and commit everyone? You could if 2PC was ubiquitous, which is certainly wasn't when the code was designed (remember, it was originally compatible all the way back to 7.3). Some people suggested using 2PC "if it's there", but that just seems to me to be asking for really painful problems. It also entails that all DDL has to happen on every node at the same time, which imposes a bottleneck not actually currently in the system. Since DDL is infrequent, is that bottleneck an acceptable trade-off? Define infrequent? I have customers that do it, everyday in prod. They do it willingly and refuse to change that habit. Even 2 or 3 ALTER TABLE or CREATE INDEX or CREATE TABLE statements per day is a drop in the bucket compared to the number of I/U/D statements, no? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: One last Slony question (was Re: [GENERAL] Slightly OT.)
Ron Johnson wrote: On 06/01/07 18:35, Joshua D. Drake wrote: Since DDL is infrequent, is that bottleneck an acceptable trade-off? Define infrequent? I have customers that do it, everyday in prod. They do it willingly and refuse to change that habit. Even 2 or 3 ALTER TABLE or CREATE INDEX or CREATE TABLE statements per day is a drop in the bucket compared to the number of I/U/D statements, no? True. J -- === 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 PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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: One last Slony question (was Re: [GENERAL] Slightly OT.)
On 06/01/07 19:17, Joshua D. Drake wrote: Ron Johnson wrote: On 06/01/07 18:35, Joshua D. Drake wrote: Since DDL is infrequent, is that bottleneck an acceptable trade-off? Define infrequent? I have customers that do it, everyday in prod. They do it willingly and refuse to change that habit. Even 2 or 3 ALTER TABLE or CREATE INDEX or CREATE TABLE statements per day is a drop in the bucket compared to the number of I/U/D statements, no? True. So Alexander Staubo's idea of synchronous DDL replication via 2PC has some merit? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: One last Slony question (was Re: [GENERAL] Slightly OT.)
On Fri, Jun 01, 2007 at 06:15:40PM -0500, Ron Johnson wrote: > > Since DDL is infrequent, is that bottleneck an acceptable trade-off? I don't know. We'd have to do the analysis. But it could be a problem. Look at it this way: if you have a replica that is, for isntance, _always_ 30 minutes behind, as a sort of poor-person's fast-recovery PITR, then you lose that functionality if you have to perform DDL on the replica at the same time as on the origin, because you have to catch up first. A -- Andrew Sullivan | [EMAIL PROTECTED] "The year's penultimate month" is not in truth a good way of saying November. --H.W. Fowler ---(end of broadcast)--- TIP 6: explain analyze is your friend
