Обсуждение: Few questions on postgresql (dblink, 2pc, clustering)
Hi list, My boss would like to convert from MySQL to PostgreSQL, but there are a few things that hold us back. We'd like to have the databases in several physical servers, with referential integrity between the tables. Reading from Oracle articles, their referential integrity can be done using their dblink and triggers. What I'd like to ask is whether contrib/dblink is stable? Seeing dblink in a contrib directory does bring a doubt (though we've read many success stories with dblink). And can the Oracle's way of doing referential integrity be used in PostgreSQL? Is it recommended to do that? I've read the PostgreSQL's TODO list, and I can't find anything about 2-phase commit being implemented in 8.0. Is this correct? Because I also read there's a 2PC patch being implemented (http://snaga.org/pgsql/). But progress seems to have stopped (correct me if I'm wrong). Basically, our concern is that dblink, 2PC implementation are there, but not in the PostgreSQL mainstream. Another thing that bothers us is that we can't find any multi-master clustering solution in PostgreSQL. We're actually evaluating MySQL's own clustering solution, but it's production quality release is still slated for MySQL 5.0.
Jim Worke wrote: > Hi list, > > My boss would like to convert from MySQL to PostgreSQL, but there are a few > things that hold us back. > > We'd like to have the databases in several physical servers, with referential > integrity between the tables. Reading from Oracle articles, their > referential integrity can be done using their dblink and triggers. What I'd > like to ask is whether contrib/dblink is stable? Seeing dblink in a contrib It is certainly stable, but it does not have transaction semantics like local table queries. > directory does bring a doubt (though we've read many success stories with > dblink). And can the Oracle's way of doing referential integrity be used in > PostgreSQL? Is it recommended to do that? Again, no persistent locking., > I've read the PostgreSQL's TODO list, and I can't find anything about 2-phase > commit being implemented in 8.0. Is this correct? Because I also read > there's a 2PC patch being implemented (http://snaga.org/pgsql/). But > progress seems to have stopped (correct me if I'm wrong). 2-phase isn't in 8.0 but I expect it in 8.1. > Basically, our concern is that dblink, 2PC implementation are there, but not > in the PostgreSQL mainstream. You need to understand the limitations of dblink and see if it will work for you. I can't imagine MySQl is allowing you to do this cleanly so I don't see why it would hold up a MySQL -> PostgreSQL migration. > Another thing that bothers us is that we can't find any multi-master > clustering solution in PostgreSQL. We're actually evaluating MySQL's own > clustering solution, but it's production quality release is still slated for > MySQL 5.0. The only multi-master I know of is pgcluster. There is talking of moving Slony from master/slave to multi-master but work has not started yet. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Sunday 22 August 2004 11:02, Bruce Momjian wrote: > 2-phase isn't in 8.0 but I expect it in 8.1. Is it possible to know when is 8.1 going to be released for production (an estimate)? > > > Basically, our concern is that dblink, 2PC implementation are there, but > > not in the PostgreSQL mainstream. > > You need to understand the limitations of dblink and see if it will work > for you. I can't imagine MySQl is allowing you to do this cleanly so I > don't see why it would hold up a MySQL -> PostgreSQL migration. Hmm... forgive me for saying it wrongly. We're actually "thinking" of migrating to PostgreSQL. Here's our case: We're going to do a major upgrading on our PHP code (from PHP 3 style to PHP 5.0), and was thinking of changing the database to PostgreSQL too. Currently, the number of transaction is not high, but we'd like to have a more scalable solution. MySQL does not allow cross-server database connection such as dblink. So, we're thinking of 3 alternatives: 1) Wait for MySQL clustering to be stable and put all our databases in the cluster 2) Migrate to PostgreSQL and use dblink to solve the referential integrity 3) Migrate to PostgreSQL clustering solution If (2) and (3) is not viable, then we'd rather not migrate the database to PostgreSQL for now (if it ain't broke, don't fix it)... So, it's not actually holding us up, but just that we're not able to make decision yet. > > Another thing that bothers us is that we can't find any multi-master > > clustering solution in PostgreSQL. We're actually evaluating MySQL's own > > clustering solution, but it's production quality release is still slated > > for MySQL 5.0. > > The only multi-master I know of is pgcluster. There is talking of > moving Slony from master/slave to multi-master but work has not started > yet. I don't mean to be rude or anything, but having 3rd-party solution is a scary option for a business enterprise. I know that they're stable and all, but if it's not supported by PostgreSQL themselves (i.e. included in PostgreSQL as a whole package), we're afraid that we have to change our code/design in case the product has stopped progress. For example, pgcluster's patch is for PostgreSQL 7.3.6. It's not in sync with PostgreSQL's current version (I'm not blaming the guy... He's created a very good solution and I'm thankful for that). It's just that for my company (and I guess many other companies too), it's more appealing to have a database solution that comes in a package.
Unsupported 3rd-party solutions (Was: Few questions on postgresql (dblink, 2pc, clustering))
От
Thomas Hallgren
Дата:
Jim Worke wrote: > I don't mean to be rude or anything, but having 3rd-party solution is a scary > option for a business enterprise. I know that they're stable and all, but if > it's not supported by PostgreSQL themselves (i.e. included in PostgreSQL as a > whole package), we're afraid that we have to change our code/design in case > the product has stopped progress. > > For example, pgcluster's patch is for PostgreSQL 7.3.6. It's not in sync with > PostgreSQL's current version (I'm not blaming the guy... He's created a very > good solution and I'm thankful for that). It's just that for my company (and > I guess many other companies too), it's more appealing to have a database > solution that comes in a package. > Those are very interesting remarks. I'm the author of PL/Java, a module that also could be thought of as "not supported by PostgreSQL themselves", and I've made the same reflection as you have. It would be beneficial to have some organisational entity within Postgres where this issue could be addressed (i.e. packaging/synchronization and supported configurations). I think it could give a real boost to PostgreSQL as such. Sure, an open source community does not make support commitments. But the PostgreSQL community is large and that creates (a sense of) safety and continuity. This sense is not automatically transferred to the "3rd-party solutions". From a users perspective and perhaps especially from the decision makers perspective, the fact that you have to download various modules from gborg etc. is indeed scary. Who will support your chosen solution a year from now? IMHO, if PosgreSQL is aiming for larger business acceptance, this has to be resolved. Contributors like myself must be given the opportunity to get things "verified" and checked in as "supported". It would do PostgreSQL an awful lot of good if there where supported configurations including replication, server side language support (Perl, Tcl, Java, etc.), JDBC and ODCB drivers, and other things that you'd normally find in commercial enterprise solutions. Regards, Thomas Hallgren
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Worke wrote: | On Sunday 22 August 2004 11:02, Bruce Momjian wrote: | |>2-phase isn't in 8.0 but I expect it in 8.1. | | | Is it possible to know when is 8.1 going to be released for production (an | estimate)? Consider that 8.0 will be release *may be* during the end of this year. Usually a development cycle between two release is 9 month and + 3 month beta let me say: 8.1 will be release in 12 months. The core will try to have a shortest cycle for 8.1 but I'll not bet on it. |>>Basically, our concern is that dblink, 2PC implementation are there, but |>>not in the PostgreSQL mainstream. |> |>You need to understand the limitations of dblink and see if it will work |>for you. I can't imagine MySQl is allowing you to do this cleanly so I |>don't see why it would hold up a MySQL -> PostgreSQL migration. | Hmm... forgive me for saying it wrongly. We're actually "thinking" of | migrating to PostgreSQL. Here's our case: | | We're going to do a major upgrading on our PHP code (from PHP 3 style to PHP | 5.0), and was thinking of changing the database to PostgreSQL too. | Currently, the number of transaction is not high, but we'd like to have a | more scalable solution. | | MySQL does not allow cross-server database connection such as dblink. So, | we're thinking of 3 alternatives: | | 1) Wait for MySQL clustering to be stable and put all our databases in the | cluster | 2) Migrate to PostgreSQL and use dblink to solve the referential integrity | 3) Migrate to PostgreSQL clustering solution May I know why are you sticky on the idea of spread your database among various servers ? Free your mysql-minded. If you idea is an horizontal scale solution then open your wallet and buy Oracle. Postgresql scale very well vertically. <SciencieFiction> Another solution is hack the postmaster in order to have two parallel postmaster running on the same server ( first phase ), when you did this successfully then the second phase ( to hack too ) is buy the hardware that permit more servers to share an unique shared memory segment and then with the help of SAN you can have two postmaster that are running on two different server that are belonging to a SAN and the common shared memory segment. </ScienceFiction> Right now your only solution is buy a multiprocessor machine. Regards Gaetano Mendola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBKG6x7UpzwH2SGd4RAn06AKCQ50Nbp8qvNlMQt2TZqCEcrsMWdgCgphRC aAn1xCqgGYIh0KtSy3s4zSI= =iDku -----END PGP SIGNATURE-----
On Sunday 22 August 2004 16:45, you wrote: > Jim Worke wrote: > > I don't mean to be rude or anything, but having 3rd-party solution is a > > scary option for a business enterprise. I know that they're stable and > > all, but if it's not supported by PostgreSQL themselves (i.e. included in > > PostgreSQL as a whole package), we're afraid that we have to change our > > code/design in case the product has stopped progress. > > > > For example, pgcluster's patch is for PostgreSQL 7.3.6. It's not in sync > > with PostgreSQL's current version (I'm not blaming the guy... He's > > created a very good solution and I'm thankful for that). It's just that > > for my company (and I guess many other companies too), it's more > > appealing to have a database solution that comes in a package. > > Those are very interesting remarks. I'm the author of PL/Java, a module > that also could be thought of as "not supported by PostgreSQL > themselves", and I've made the same reflection as you have. It would be > beneficial to have some organisational entity within Postgres where this > issue could be addressed (i.e. packaging/synchronization and supported > configurations). I think it could give a real boost to PostgreSQL as such. > > Sure, an open source community does not make support commitments. But > the PostgreSQL community is large and that creates (a sense of) safety > and continuity. This sense is not automatically transferred to the > "3rd-party solutions". > > From a users perspective and perhaps especially from the decision > makers perspective, the fact that you have to download various modules > from gborg etc. is indeed scary. Who will support your chosen solution a > year from now? IMHO, if PosgreSQL is aiming for larger business > acceptance, this has to be resolved. Contributors like myself must be > given the opportunity to get things "verified" and checked in as > "supported". It would do PostgreSQL an awful lot of good if there where > supported configurations including replication, server side language > support (Perl, Tcl, Java, etc.), JDBC and ODCB drivers, and other things > that you'd normally find in commercial enterprise solutions. I'm CC'ing this to the postgresql mailing list. I fully agree to your statement (to get things "verified" and checked in as "supported"). Hopefully there's a way out for this...
I think the major question would still remain, "What is that worth?", if PostGreSQL says that the software works with their product. If there was a problem with it, or if the developer decided not to upgrade to a new version with the main product, there is still no warranty. PostGreSQL will probably not pick up the development and upgrade it themselves. This is very similar to asking the Linux distributions to officially support PostGreSQL. They do to a level, but that includes just the installation. If they upgrade and PostGreSQL in not compliant with them anymore they will tell you they do not support it anymore. If you think about it, PostGreSQL is a third-party product to the Operating System. I don't think PostGreSQL is officially "REDHAT compliant" (as an example). Then this supporting software is third-party to the DBMS. This seems to be the way OpenSource works. I agree with you that a third-party solution may not be the most comfortable thing to do, but that is one of the inherent risks when going Open Source. There is also no guarantee on PostGreSQL doing what it is supposed to or what they say it does. The only difference between using PostGreSQL and using a product that works with PostGreSQL is that you have increased your risk. It was not like you were in the safe-zone and were determining whether to take a risk or not. ________________________________________________________________________________ On Sunday 22 August 2004 16:45, you wrote: > Jim Worke wrote: > > I don't mean to be rude or anything, but having 3rd-party solution is a > > scary option for a business enterprise. I know that they're stable and > > all, but if it's not supported by PostgreSQL themselves (i.e. included in > > PostgreSQL as a whole package), we're afraid that we have to change our > > code/design in case the product has stopped progress. > > > > For example, pgcluster's patch is for PostgreSQL 7.3.6. It's not in sync > > with PostgreSQL's current version (I'm not blaming the guy... He's > > created a very good solution and I'm thankful for that). It's just that > > for my company (and I guess many other companies too), it's more > > appealing to have a database solution that comes in a package. > > Those are very interesting remarks. I'm the author of PL/Java, a module > that also could be thought of as "not supported by PostgreSQL > themselves", and I've made the same reflection as you have. It would be > beneficial to have some organisational entity within Postgres where this > issue could be addressed (i.e. packaging/synchronization and supported > configurations). I think it could give a real boost to PostgreSQL as such. > > Sure, an open source community does not make support commitments. But > the PostgreSQL community is large and that creates (a sense of) safety > and continuity. This sense is not automatically transferred to the > "3rd-party solutions". > > From a users perspective and perhaps especially from the decision > makers perspective, the fact that you have to download various modules > from gborg etc. is indeed scary. Who will support your chosen solution a > year from now? IMHO, if PosgreSQL is aiming for larger business > acceptance, this has to be resolved. Contributors like myself must be > given the opportunity to get things "verified" and checked in as > "supported". It would do PostgreSQL an awful lot of good if there where > supported configurations including replication, server side language > support (Perl, Tcl, Java, etc.), JDBC and ODCB drivers, and other things > that you'd normally find in commercial enterprise solutions. I'm CC'ing this to the postgresql mailing list. I fully agree to your statement (to get things "verified" and checked in as "supported"). Hopefully there's a way out for this... ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
After a long battle with technology, mendola@bigfoot.com (Gaetano Mendola), an earthling, wrote:
> | MySQL does not allow cross-server database connection such as dblink. So,
> | we're thinking of 3 alternatives:
> |
> | 1) Wait for MySQL clustering to be stable and put all our databases in the
> | cluster
> | 2) Migrate to PostgreSQL and use dblink to solve the referential integrity
> | 3) Migrate to PostgreSQL clustering solution
>
> May I know why are you sticky on the idea of spread your database
> among various servers ? Free your mysql-minded. If you idea is an
> horizontal scale solution then open your wallet and buy Oracle.
> Postgresql scale very well vertically.
Indeed.
It seems quite unclear what the proposed merit of "clustering" is
_supposed_ to be, and I think it bears asking Jim Worke to explain in
more detail what they're trying to accomplish by it.
- If the goal is improved redundancy, then I'd argue that doing all
the updates on the "master" and having several "hot replicas" being
maintained using Slony-I would accomplish that without technology
changes.
- If the goal is to somehow get better performance by partitioning
work across multiple servers, then this can be attained by having
those several "hot replicas," and directing as many read-only
operations to replicas as possible. Updates have to go to the
"master;" by dropping out query load, that lets the "master" be
occupied primarily with write operations.
- System reliability does NOT improve if write operations are
spread across several servers. We have been setting up extra
replicas of some databases on some new servers lately, and people
that _haven't_ thought it out have briefly imagined it a good idea
to spread the 'masters' across more servers, which would _hurt_
reliability, in fact.
The situation we have is that our app needs access to two
databases: one that stores "state," and another that logs activity.
The theory that people come up with is that when we have 3 main "big
servers," we should write the "state" to one, and logs to another.
Reality rears its ugly head: Doing that makes the system more
vulnerable, as if _either_ of those servers goes down, that will
cause the application to go into convulsions. Putting "state" and
"logs" on the same server, and replicating everywhere else is, in
fact, the more reliable choice. If the ONE server that's "master"
goes down, the application won't be happy, but that was always going
to be the case.
The point: Distributing writes across many hosts makes the system
vulnerable to the possibility of _any_ of them going down.
Furthermore, it is not evident that distributing writes will be able
to actually improve performance, because it introduces substantial
additional communications overhead.
At some point, there will be parts of the write activities that have
to be handled in a serial manner, in one place. For instance,
updating and reporting account balances must ultimately be thus
handled. If there are 10 customers fighting over who gets to order
your last 20 pallets of "Grapple Grommets," the handling of who
actually gets that inventory has _got_ to be serialized in one place
if you don't want to run the risk of the over-commitment of perhaps
promising 200 pallets worth when you only have 20.
2PC provides a way of managing that serialization across multiple
databases; it has two inherent problems relating to what is already
said above:
1. The communications overhead involved in coordinating requests
across multiple databases means that it's unlikely to be a
"performance win";
2. There are deadlock situations that 2PC is vulnerable to that
make it _less_ reliable than having just one database, when
there is the possibility of hardware or communications
failure.
Note: These aren't PostgreSQL-specific issues; they apply to the
various classes of "clustering solutions." It may be that Oracle or
DB2 or Informix have some particular features that partially relieve
some of the performance problems with "partitioning," but that still
leaves a big bill to pay, and you'd better be sure you're getting
some actual value for the extra coin...
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/spiritual.html
Signs of a Klingon Programmer #8: "What is this talk of 'release'?
Klingons do not make software 'releases.' Our software 'escapes'
leaving a bloody trail of designers and quality assurance people in
its wake."
Sim, > I think the major question would still remain, "What is that worth?", > if PostGreSQL says that the software works with their product. If there was a problem with it, or > if the developer decided not to upgrade to a new version with the main > product, there is still no warranty. PostGreSQL will probably not pick > up the development and upgrade it themselves. > I agree that if that was the case, the whole exercise would be pointless. > I agree with you that a third-party solution may not be the most > comfortable thing to do, but that is one of the inherent risks when > going Open Source. There is also no guarantee on PostGreSQL doing what > it is supposed to or what they say it does. The only difference > between using PostGreSQL and using a product that works with > PostGreSQL is that you have increased your risk. It was not like you > were in the safe-zone and were determining whether to take a risk or > not. I agree here too. But I think there's more to it. There's a lot of PostgreSQL users out there today. The community is very large and the risk of it going down the drain any time soon is extremely small. The risk of using a third party product however, is on the opposite side of that scale. This is bad for all partys involved. It's bad for PostgreSQL as a whole, for the third party product, and for all users, potential or existing. So, my suggestion is that the "verify" to get a "supported" status would actually mean something. It would mean that the PostgreSQL community has a real interest in the product and that they have every intention to maintain it. Such a "commitment" would of course not be binding in any way but it would state an intent. I think that would be very valuable to everyone! Combine that with pre-packaged distributions containing the supported modules to be found at the PostgreSQL web site. You ask "What is that worth?". I for one claim it's worth a great deal. It would really motivate me (and I imagine others) to go further with my product. It would give potential users a "product" that contain everything they want it to contain. It strengthen PostgreSQL's position as the most advanced free database in the market even more. Regards, Thomas Hallgren
On Sun, 22 Aug 2004, Thomas Hallgren wrote: > Combine that with pre-packaged distributions containing the supported > modules to be found at the PostgreSQL web site. You ask "What is that > worth?". I for one claim it's worth a great deal. It would really > motivate me (and I imagine others) to go further with my product. It > would give potential users a "product" that contain everything they want > it to contain. It strengthen PostgreSQL's position as the most advanced > free database in the market even more. Its actually worth alot less then you think ... for instance, if we were to import Slony as part of 8.0 (we won't, but its an example) since it is "todays fashion for replication", there is no guarantee that for 8.1, we don't replace it with something that happens to be better then ... then the person that deployed Slony because it was 'the fashion of the day' is now using something that is no longer considered "supported"? Do they change then? libpq++ is a better example, because it happened ... nobody was working on it, and someone came along and decided that since he felt it was too broken, he started to develop his own which became better then what we had in the tree, even though the one in the tree was considered "the supported one" ... The benefit (and drawback) to OSS is that it is possible to have several potential solutions to the same problem ... in 6 months time, who says there is no second (or third) implementation of PL/Java out there? Or pl/PHP? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Thomas Hallgren <thhal@mailblocks.com> writes:
> ... the fact that you have to download various modules
> from gborg etc. is indeed scary. Who will support your chosen solution a
> year from now? IMHO, if PosgreSQL is aiming for larger business
> acceptance, this has to be resolved. Contributors like myself must be
> given the opportunity to get things "verified" and checked in as
> "supported". It would do PostgreSQL an awful lot of good if there where
> supported configurations including replication, server side language
> support (Perl, Tcl, Java, etc.), JDBC and ODCB drivers, and other things
> that you'd normally find in commercial enterprise solutions.
Supported by *whom* exactly? It won't be the core committee; we have
more than enough to do managing the server itself.
Whoever is actually doing this "verifying" and "supporting" can take
on the work of producing the "supported configuration" package too;
IMHO it would really be pretty meaningless to do otherwise.
I think the place where this most naturally falls is with the commercial
Linux distributors (Red Hat, Suse, etc). They're already in the
business of assembling disparate upstream sources and making sure those
bits play nicely together.
regards, tom lane
Marc, > Its actually worth alot less then you think ... for instance, if we > were to import Slony as part of 8.0 (we won't, but its an example) > since it is "todays fashion for replication", there is no guarantee > that for 8.1, we don't replace it with something that happens to be > better then ... then the person that deployed Slony because it was > 'the fashion of the day' is now using something that is no longer > considered "supported"? Do they change then? > > libpq++ is a better example, because it happened ... nobody was > working on it, and someone came along and decided that since he felt > it was too broken, he started to develop his own which became better > then what we had in the tree, even though the one in the tree was > considered "the supported one" ... I never said that the conglomerate of "supported" add-ons should be static. On the contrary! The entity behind what I'm proposing should strive to provide "best of breed" solutions. The fact that you actually replace a dying module with a superior vital one is not negative to anyone as long as you provide a migration path. What do you think would happen if the libpq++ replacement was acknowledged and supported by PostgreSQL provided the people behind it made migration simple for existing libpq++ users (the question is hypothetical, I have no clue how easy or difficult such a migration is in real life)? > The benefit (and drawback) to OSS is that it is possible to have > several potential solutions to the same problem ... in 6 months time, > who says there is no second (or third) implementation of PL/Java out > there? Or pl/PHP? PL/Java is a good example since it's one of two server side Java solutions. The other one is PL/J. While they provide the same functionality, they are fundamentally different in implementation and the best choice is likely to vary depending on the intended use (this is b.t.w. very true for different replication solutions also, so the remainder of this argument is not specific to server side java). There's nothing wrong with this. PostgreSQL could support more than one solution and provide guidelines describing when one is a better solution then the other(s). Further more, PostgreSQL could put up some requirements to the contributors so that they where inclined to expose somewhat similar interfaces to the end user, thereby making it easy for the end user to try out more than one. Should yet another solution pop up, well then the contributor of that one has to motivate why it too should be supported. Perhaps the motivation is that it's very similar to an existing solution but it shows superior performance and stability. When that happens (and is proven), the existing solution is replaced. The contributor of the new solution must of course ensure ease of migration. A solution that is judged equal or not as good should be rejected on the base that a viable solution that perfoms same task is already supported. It's no different from accepting or rejecting patches really. It's just on a larger scale. Some efforts could be made to encourage potential contributors of new modules to get involved with existing work instead of providing new solutions for already existing ones (such as with the libpg++). The advantage with OSS is that an offer to contribute is very often gladly accepted by the project owner :-) Regards, Thomas Hallgren
Tom, > Supported by *whom* exactly? It won't be the core committee; we have > more than enough to do managing the server itself. > I don't doubt that for a second. What I'm suggesting must be staffed somehow. The core committee must be involved though or the whole idea falls apart. You *are* PostgreSQL (at least to me). > Whoever is actually doing this "verifying" and "supporting" can take > on the work of producing the "supported configuration" package too; > IMHO it would really be pretty meaningless to do otherwise. > Agree. > I think the place where this most naturally falls is with the commercial > Linux distributors (Red Hat, Suse, etc). They're already in the > business of assembling disparate upstream sources and making sure those > bits play nicely together. > Here I don't agree. It's very important that the packaging is made by PostgreSQL. I'm not contributing PL/Java for the benefit of Red Hat or Suse. I'm doing it because I want to improve the database. Also, when a Solaris or Windows customer wants a database solution, it's higly unlikely that they'd consult a commercial Linux distributor. Regards, Thomas Hallgren
Oops! thhal@mailblocks.com (Thomas Hallgren) was seen spray-painting on a wall: > So, my suggestion is that the "verify" to get a "supported" status > would actually mean something. It would mean that the PostgreSQL > community has a real interest in the product and that they have > every intention to maintain it. Such a "commitment" would of course > not be binding in any way but it would state an intent. I think that > would be very valuable to everyone! I'd suggest that the "pgxs" work is pointed at making it easier to do this sort of thing. Make it easier to add in third party packages in a repeatable, testable way, and that makes it easier to make the "3rd party" material supportable. -- select 'cbbrowne' || '@' || 'ntlug.org'; http://www3.sympatico.ca/cbbrowne/emacs.html "What if you slept? And what if, in your sleep, you dreamed? And what if, in your dream, you went to heaven and there plucked a strange and beautiful flower? And what if, when you awoke, you had the flower in your hand? Ah, what then?" --Coleridge
Thomas Hallgren wrote: > Tom, > > Supported by *whom* exactly? It won't be the core committee; we have > > more than enough to do managing the server itself. > > > I don't doubt that for a second. What I'm suggesting must be staffed > somehow. The core committee must be involved though or the whole idea > falls apart. You *are* PostgreSQL (at least to me). Have you seen the discussion about the MONEY type on the hackers list today? We don't even have the manpower to _remove_ or _adjust_ an existing data type that we know has been broken for perhaps +3 years. How are we going to find time to do more about integrating and supporting more software? Answer me that and we can move forward. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Sunday 22 August 2004 21:44, you wrote: > After a long battle with technology, mendola@bigfoot.com (Gaetano Mendola), an earthling, wrote: > > | MySQL does not allow cross-server database connection such as dblink. > > | So, we're thinking of 3 alternatives: > > | > > | 1) Wait for MySQL clustering to be stable and put all our databases in > > | the cluster > > | 2) Migrate to PostgreSQL and use dblink to solve the referential > > | integrity 3) Migrate to PostgreSQL clustering solution > > > > May I know why are you sticky on the idea of spread your database > > among various servers ? Free your mysql-minded. If you idea is an > > horizontal scale solution then open your wallet and buy Oracle. > > Postgresql scale very well vertically. > > Indeed. > > It seems quite unclear what the proposed merit of "clustering" is > _supposed_ to be, and I think it bears asking Jim Worke to explain in > more detail what they're trying to accomplish by it. Sorry. Been rather confused with so many things that need to be done, sometimes I focused on what I want rather than what I need. > > - If the goal is improved redundancy, then I'd argue that doing all > the updates on the "master" and having several "hot replicas" being > maintained using Slony-I would accomplish that without technology > changes. Yes indeed it would and I'm going to try it out soon :) Actually we're also planning an exercise to replicate the database to a data recovery site. When everything is ready, we'd like the new site to be the primary site (the clients will be switched to the new site at an instance by my ISP). That's why I was thinking that, if there is a multi-master replication, the clients can be switched to the new site and the old site still have the new data. So any transaction consolidation would not be disrupted. I guess I should've said the above earlier rather than ask ABOUT the solution :) > > - If the goal is to somehow get better performance by partitioning > work across multiple servers, then this can be attained by having > those several "hot replicas," and directing as many read-only > operations to replicas as possible. Updates have to go to the > "master;" by dropping out query load, that lets the "master" be > occupied primarily with write operations. I was hoping not having to change the application code by changing queries to one server and updates to another server. > > - System reliability does NOT improve if write operations are > spread across several servers. We have been setting up extra > replicas of some databases on some new servers lately, and people > that _haven't_ thought it out have briefly imagined it a good idea > to spread the 'masters' across more servers, which would _hurt_ > reliability, in fact. > > The situation we have is that our app needs access to two > databases: one that stores "state," and another that logs activity. > > The theory that people come up with is that when we have 3 main "big > servers," we should write the "state" to one, and logs to another. > > Reality rears its ugly head: Doing that makes the system more > vulnerable, as if _either_ of those servers goes down, that will > cause the application to go into convulsions. Putting "state" and > "logs" on the same server, and replicating everywhere else is, in > fact, the more reliable choice. If the ONE server that's "master" > goes down, the application won't be happy, but that was always going > to be the case. > > The point: Distributing writes across many hosts makes the system > vulnerable to the possibility of _any_ of them going down. Yes, that is true. So separating databases across servers shouldn't be the way to go. Thanks.
On Sun, 22 Aug 2004, Thomas Hallgren wrote: > PL/Java is a good example since it's one of two server side Java > solutions. The other one is PL/J. While they provide the same > functionality, they are fundamentally different in implementation and > the best choice is likely to vary depending on the intended use (this is > b.t.w. very true for different replication solutions also, so the > remainder of this argument is not specific to server side java). Since I (and I don't believe anyone else on core) uses Java ... shouldn't it be up to the developer of the PL/J* modules to do this? We can't weigh which one is better then the other, as we don't use it ... Also, how does someone support something that they don't use? Again, that is the developer of PL/J*'s job to do, not ours ... > Should yet another solution pop up, well then the contributor of that > one has to motivate why it too should be supported. Perhaps the > motivation is that it's very similar to an existing solution but it > shows superior performance and stability. When that happens (and is > proven), the existing solution is replaced. The contributor of the new > solution must of course ensure ease of migration. At that rate, we'll have to distribute via CD to anyone that wants PostgreSQL ... cause downloading it via FTP won't be a viable option anymore :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc, > Since I (and I don't believe anyone else on core) uses Java ... > shouldn't it be up to the developer of the PL/J* modules to do this? We > can't weigh which one is better then the other, as we don't use it ... > Of course the contributors should supply as much of this material as possible. The point I'm trying to make is that there's often no incentive to do so, nor a good place to put it. > Also, how does someone support something that they don't use? Again, > that is the developer of PL/J*'s job to do, not ours ... > Again, I'm not trying to offload work from the contributors onto the members of core. This is about how things are perceived by the PostgreSQL customers. Of course the contributors must continue to support their products. If they don't, I'd expect the "supported" status to be dropped at some point. > At that rate, we'll have to distribute via CD to anyone that wants > PostgreSQL ... cause downloading it via FTP won't be a viable option > anymore :) > In times when people download gigabytes of film and music using BitTorrent, I think that's the least of our problems. But of course, the distribution should be kept at a reasonable size. That's why I'd like a better solution to replace the inferior one and to limit the number of overlaps. Regards, Thomas Hallgren
On 8/21/2004 10:34 PM, Jim Worke wrote: > Another thing that bothers us is that we can't find any multi-master > clustering solution in PostgreSQL. We're actually evaluating MySQL's own > clustering solution, but it's production quality release is still slated for > MySQL 5.0. And with all the different table types available, MySQL has successfully created a lot of confusion. Note that all the latest and greatest features that became available with InnoDB tables will again be on your wishlist when using NDB Cluster. InnoDB and NDB Cluster transactions are not ACID together, only each of them inside of its table handler is. NDB Cluster tables will not support foreign keys and the last I heard was that unique constraints are pretty expensive because of their "funky" implementation as separate tables. Another little detail is that NDB Cluster is an in-memory table type. And to get your failover capabilities, the data must be in memory at least twice. So you need 2x your entire DB size plus overhead like OS and a little room to breathe in RAM. With a 100GB database, this will get funny on the network side too because you will want to have better than gigabit ethernet. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Thomas Hallgren wrote: > Marc, > > Since I (and I don't believe anyone else on core) uses Java ... > > shouldn't it be up to the developer of the PL/J* modules to do this? We > > can't weigh which one is better then the other, as we don't use it ... > > > Of course the contributors should supply as much of this material as > possible. The point I'm trying to make is that there's often no > incentive to do so, nor a good place to put it. What incentive do you want us to give? We don't have any. And if someone does it, we will find a place for it. > > Also, how does someone support something that they don't use? Again, > > that is the developer of PL/J*'s job to do, not ours ... > > > Again, I'm not trying to offload work from the contributors onto the > members of core. This is about how things are perceived by the > PostgreSQL customers. Of course the contributors must continue to > support their products. If they don't, I'd expect the "supported" status > to be dropped at some point. I think you want us to look more like a MySQL AB or Oracle company where things are more bundled and blessed. It isn't going to happen with us because we aren't a company, don't make money, and don't control anyone. This reminds me of the MySQL migration guy who didn't want to use a 3rd party replicaiton solution. I really wanted to say he might be happier with MySQL. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Mon, 23 Aug 2004, Thomas Hallgren wrote: > Again, I'm not trying to offload work from the contributors onto the members > of core. This is about how things are perceived by the PostgreSQL customers. > Of course the contributors must continue to support their products. If they > don't, I'd expect the "supported" status to be dropped at some point. Except that what you are missing is that each if the individual package is 'supported' to a certain extent, it doesn't negate the amount of work that the developers (more often then not, the core developers for stuff like this) having to maintain and test the build system ... and the more we 'include', the more onerous that task will be until such a point that the 'core server' won't get any work done on it, since all the time will be spent on "packaging the latest and greatest solution for foo" ... > In times when people download gigabytes of film and music using BitTorrent, I > think that's the least of our problems. But of course, the distribution > should be kept at a reasonable size. That's why I'd like a better solution to > replace the inferior one and to limit the number of overlaps. At which time we are once more 'playing favorites' ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Hi all, Bruce, if postgres is not a company and so on, why don't you open up the core development team to include some of the contributors who would like to include their product in the main distribution, and have a bundled product ? Cause a good data base is definitely not made up just by the core, but all the rest too. And I'm sure that there are many people out there who would use a PL/Java if they would find it in the main distribution, and that's all you have to do for this to happen: include it. Users of postgres are busy too, and some of them will never notice what they are missing. Now it's very clear to me that if all the extensions would be bundled, it would be too much, and that there's no "commitee" to steer what should go in or out... but then maybe a vote would help ? If the contributor wants it in the core, a vote of the interested would be quite relevant. <joke> Or write a plugin manager like of the better Java IDEs, to automatically search/select/download/install plugins for your currently running version ;-) </joke> Cheers, Csaba. > > Again, I'm not trying to offload work from the contributors onto the > > members of core. This is about how things are perceived by the > > PostgreSQL customers. Of course the contributors must continue to > > support their products. If they don't, I'd expect the "supported" status > > to be dropped at some point. > > I think you want us to look more like a MySQL AB or Oracle company where > things are more bundled and blessed. It isn't going to happen with us > because we aren't a company, don't make money, and don't control anyone. > > This reminds me of the MySQL migration guy who didn't want to use a 3rd > party replicaiton solution. I really wanted to say he might be happier > with MySQL.
Csaba Nagy wrote: > Hi all, > > Bruce, if postgres is not a company and so on, why don't you open up the > core development team to include some of the contributors who would like > to include their product in the main distribution, and have a bundled > product ? Cause a good data base is definitely not made up just by the > core, but all the rest too. And I'm sure that there are many people out > there who would use a PL/Java if they would find it in the main > distribution, and that's all you have to do for this to happen: include > it. Users of postgres are busy too, and some of them will never notice > what they are missing. > Now it's very clear to me that if all the extensions would be bundled, > it would be too much, and that there's no "commitee" to steer what > should go in or out... but then maybe a vote would help ? If the > contributor wants it in the core, a vote of the interested would be > quite relevant. We are not adverse to someone taking the core db code, adding other stuff, and making a new super distribution. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian wrote: > Csaba Nagy wrote: > >>Hi all, >> >>Bruce, if postgres is not a company and so on, why don't you open up the >>core development team to include some of the contributors who would like >>to include their product in the main distribution, and have a bundled >>product ? Cause a good data base is definitely not made up just by the >>core, but all the rest too. And I'm sure that there are many people out >>there who would use a PL/Java if they would find it in the main >>distribution, and that's all you have to do for this to happen: include >>it. Users of postgres are busy too, and some of them will never notice >>what they are missing. >>Now it's very clear to me that if all the extensions would be bundled, >>it would be too much, and that there's no "commitee" to steer what >>should go in or out... but then maybe a vote would help ? If the >>contributor wants it in the core, a vote of the interested would be >>quite relevant. > > > We are not adverse to someone taking the core db code, adding other > stuff, and making a new super distribution. And? Put it on www.postgresql.org ? Are you proposing to do a sort of "linux kernel" : "Red Hat" = postgresql : "super distribution" ? Is this the way that the core is following? Is the time mature enough ? Regards Gaetano Mendola
As Tom (I believe) has stated, and both Bruce/I have said over and over again ... this is nothing stop'ng a group of ppl starting up a "bundled postgresql" project, and dedicating their time and effort into building something up ... As Peter has stated, he had thought of this in the past, and felt it was easier/better for the various OS distributions to do it on their own ... In fact, Linux and FreeBSD *both* already deal with this in their RPM/ports collections ... and, in fact, on the FreeBSD side, smaller is better then larger, so that packager maintainers don't hvae to download a 12Meg file to get a 1Meg port out of it ... On Mon, 23 Aug 2004, Csaba Nagy wrote: > Hi all, > > Bruce, if postgres is not a company and so on, why don't you open up the > core development team to include some of the contributors who would like > to include their product in the main distribution, and have a bundled > product ? Cause a good data base is definitely not made up just by the > core, but all the rest too. And I'm sure that there are many people out > there who would use a PL/Java if they would find it in the main > distribution, and that's all you have to do for this to happen: include > it. Users of postgres are busy too, and some of them will never notice > what they are missing. > Now it's very clear to me that if all the extensions would be bundled, > it would be too much, and that there's no "commitee" to steer what > should go in or out... but then maybe a vote would help ? If the > contributor wants it in the core, a vote of the interested would be > quite relevant. > > <joke> > Or write a plugin manager like of the better Java IDEs, to automatically > search/select/download/install plugins for your currently running > version ;-) > </joke> > > Cheers, > Csaba. > > >>> Again, I'm not trying to offload work from the contributors onto the >>> members of core. This is about how things are perceived by the >>> PostgreSQL customers. Of course the contributors must continue to >>> support their products. If they don't, I'd expect the "supported" status >>> to be dropped at some point. >> >> I think you want us to look more like a MySQL AB or Oracle company where >> things are more bundled and blessed. It isn't going to happen with us >> because we aren't a company, don't make money, and don't control anyone. >> >> This reminds me of the MySQL migration guy who didn't want to use a 3rd >> party replicaiton solution. I really wanted to say he might be happier >> with MySQL. > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 23 Aug 2004, Gaetano Mendola wrote: > Bruce Momjian wrote: > >> Csaba Nagy wrote: >> >>> Hi all, >>> >>> Bruce, if postgres is not a company and so on, why don't you open up the >>> core development team to include some of the contributors who would like >>> to include their product in the main distribution, and have a bundled >>> product ? Cause a good data base is definitely not made up just by the >>> core, but all the rest too. And I'm sure that there are many people out >>> there who would use a PL/Java if they would find it in the main >>> distribution, and that's all you have to do for this to happen: include >>> it. Users of postgres are busy too, and some of them will never notice >>> what they are missing. >>> Now it's very clear to me that if all the extensions would be bundled, >>> it would be too much, and that there's no "commitee" to steer what >>> should go in or out... but then maybe a vote would help ? If the >>> contributor wants it in the core, a vote of the interested would be >>> quite relevant. >> >> >> We are not adverse to someone taking the core db code, adding other >> stuff, and making a new super distribution. > > And? Put it on www.postgresql.org ? No ... put it on pgFoundry.org as a project there ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > > As Tom (I believe) has stated, and both Bruce/I have said over and over > again ... this is nothing stop'ng a group of ppl starting up a "bundled > postgresql" project, and dedicating their time and effort into building > something up ... > > As Peter has stated, he had thought of this in the past, and felt it was > easier/better for the various OS distributions to do it on their own ... This argument fail given the absence of a tool that avoid to do a dump-initdb-restore cicle. My example ( I think that I'm the average user case ): we have a RH AS 2.1 installation, we are sticky to this release ( a RH AS 3.0 is not yet supported by the Hardaware provider ) and RH doesn't provide the RPM for 7.4, the RH postgres version for that distribution is still the 7.2 IIRC. Regards Gaetano Mendola
Marc G. Fournier wrote: > Except that what you are missing is that each if the individual > package is 'supported' to a certain extent, it doesn't negate the > amount of work that the developers (more often then not, the core > developers for stuff like this) having to maintain and test the build > system ... and the more we 'include', the more onerous that task will > be until such a point that the 'core server' won't get any work done > on it, since all the time will be spent on "packaging the latest and > greatest solution for foo" ... Moving things in under the PostgreSQL does not have to be equal to moving all the work over to the core developers. The contributors must of course still do what they do today. That includes testing (and documenting, answer questions on mailing lists, etc.). A great advantage would be that this time the testing would be made using a common test infrastructure enforced by the (extended) comittee and the documentation would become part of the PostgreSQL docs. In essence, you would actually get more people involved in the common infrastructure, thus lessen the strain on the core developers. I said before that I don't doubt for a second that you are totally busy with the core backend. My suggestion is not that you take on more work but rather that the comittee is allowed to grow and take on responsabilities and people beyond the developers of the core database. >> In times when people download gigabytes of film and music using >> BitTorrent, I think that's the least of our problems. But of course, >> the distribution should be kept at a reasonable size. That's why I'd >> like a better solution to replace the inferior one and to limit the >> number of overlaps. > > > At which time we are once more 'playing favorites' ... Sorry, but that one got right pass me. 'playing favorites'? Regards, Thomas Hallgren
Bruce Momjian wrote: >What incentive do you want us to give? We don't have any. And if >someone does it, we will find a place for it. > > > A contributor of a product is perhaps not too eager to highlight the weaknesses and explain the use cases where another product might be a better choice :-). A committee with unbiased people, or with members from all camps, would be a much more likely group to come up with good recommendations. Especially if they, after some discussions concerning solutions, implementations, etc. ended up with two or more similar products suitable for slightly different purposes. >I think you want us to look more like a MySQL AB or Oracle company where >things are more bundled and blessed. It isn't going to happen with us >because we aren't a company, don't make money, and don't control anyone. > > > No, not really. PostgreSQL is a well established Open Source community with a good reputation and very skilled people. For many people that's even better than a company since you get rid of all the marketing bullshit. You have firm control over the core backend and you control all contributions that are made to it. I'm asking you to extend the committee and its responsibilities to so that: a) More software can make use of your good name and reputation. b) Users will find it and be able to install it easily. e) Users will consider it fairly secure to use the software. d) All developers get better reuse of, and can improve on, the core infrastructure. e) Releases would be synchronized. Regards, Thomas Hallgren
Marc G. Fournier wrote: > > As Tom (I believe) has stated, and both Bruce/I have said over and > over again ... this is nothing stop'ng a group of ppl starting up a > "bundled postgresql" project, and dedicating their time and effort > into building something up ... > > As Peter has stated, he had thought of this in the past, and felt it > was easier/better for the various OS distributions to do it on their > own ... > > In fact, Linux and FreeBSD *both* already deal with this in their > RPM/ports collections ... and, in fact, on the FreeBSD side, smaller > is better then larger, so that packager maintainers don't hvae to > download a 12Meg file to get a 1Meg port out of it ... > Bruce Momjian wrote: >We are not adverse to someone taking the core db code, adding other >stuff, and making a new super distribution. > > Your customers and many of your contributors would really like to see PostgreSQL become more then just the core backend. A Redhat bundle is great if your'e a Redhat user. If you are on another platform however, it's no good to you. And some bundle from "a group of ppl" or "someone"? No, sorry, that won't cut it either. It's just not the same thing at all. Regards, Thomas Hallgren
I think the misconception here is that the core team has customers. They don't. People use their software, because it truly kicks ass, but that's it. If less people use their software, it's unfortunate, but it's not like the core team is loosing out on anything, either. My understanding is that the core team wants to focus their limited effort on making a quality backend that will be the most use to the most people. They've expressed (many times) that they have zero interest in doing anything else. After all, why should they, when they're already overbooked and their code is free to be repackaged? My understanding is also that there are an increasing amount of people that don't like this model. They want the core team to package their specialized needs along with the core db and support it as one. Or, maybe said another way, they want all their features to come from one entity and be supported by that entity. Seems like what we have here is a golden opportunity for a business. Though, aren't there already such redhat-like consulting businesses for postgres? Aug 23, 2004, at 1:03 PM, Thomas Hallgren wrote: >> > Your customers and many of your contributors would really like to see > PostgreSQL become more then just the core backend. A Redhat bundle is > great if your'e a Redhat user. If you are on another platform however, > it's no good to you. And some bundle from "a group of ppl" or > "someone"? > No, sorry, that won't cut it either. It's just not the same thing at > all. > > Regards, > > Thomas Hallgren > > > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings
>
> A committee with unbiased people, or with members from all camps, would
> be a much more likely group to come up with good recommendations.
> Especially if they, after some discussions concerning solutions,
> implementations, etc. ended up with two or more similar products
> suitable for slightly different purposes.
1. committe == slow release
2. There is no such thing as an Unbiased person
3. Good recommendations are always reviewed within the current paradigm
of communication, look at this thread.
The more people you add to a particular process with the ability to
express their opinion, will only add to the complexity and slowness of
ANY particular project.
There is a reason CORE is small. Because it is efficient.
Although, I do believe there should be sub-core groups:
1. Core -- Main database backend -- central approval/rejection
a. plCore -- controls the release/distribution/testing etc.. of the
pl languages
b. contribCore -- products that make it into contrib
This would probably greatly reduce the load on core as a whole and allow
them to focus on the main server itself.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Вложения
> My understanding is also that there are an increasing amount of people > that don't like this model. They want the core team to package their > specialized needs along with the core db and support it as one. Or, > maybe said another way, they want all their features to come from one > entity and be supported by that entity. > > Seems like what we have here is a golden opportunity for a business. > Though, aren't there already such redhat-like consulting businesses for > postgres? What you are talking about is my Company. Command Prompt, Inc. or SRA with PowerGres. Command Prompt and SRA both offer PostgreSQL "distributions". In fact SRA offers a native Win32 version that is threaded already. Command Prompt offers its Mammoth line for Linux/OSX and Solaris and it includes replication. Sincerely, Joshua D. Drake > > Aug 23, 2004, at 1:03 PM, Thomas Hallgren wrote: > >>> >> Your customers and many of your contributors would really like to see >> PostgreSQL become more then just the core backend. A Redhat bundle is >> great if your'e a Redhat user. If you are on another platform however, >> it's no good to you. And some bundle from "a group of ppl" or "someone"? >> No, sorry, that won't cut it either. It's just not the same thing at all. >> >> Regards, >> >> Thomas Hallgren >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 7: don't forget to increase your free space map settings > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Вложения
As an example, who has the largest 8.0beta1 downloads? pginstaller. And who controls that? The pginstaller project team. It has no official relationship to anyone except it is a useful project and we mention it in the release notes. --------------------------------------------------------------------------- Thomas Hallgren wrote: > Marc G. Fournier wrote: > > > > > As Tom (I believe) has stated, and both Bruce/I have said over and > > over again ... this is nothing stop'ng a group of ppl starting up a > > "bundled postgresql" project, and dedicating their time and effort > > into building something up ... > > > > As Peter has stated, he had thought of this in the past, and felt it > > was easier/better for the various OS distributions to do it on their > > own ... > > > > In fact, Linux and FreeBSD *both* already deal with this in their > > RPM/ports collections ... and, in fact, on the FreeBSD side, smaller > > is better then larger, so that packager maintainers don't hvae to > > download a 12Meg file to get a 1Meg port out of it ... > > > Bruce Momjian wrote: > > >We are not adverse to someone taking the core db code, adding other > >stuff, and making a new super distribution. > > > > > Your customers and many of your contributors would really like to see > PostgreSQL become more then just the core backend. A Redhat bundle is > great if your'e a Redhat user. If you are on another platform however, > it's no good to you. And some bundle from "a group of ppl" or "someone"? > No, sorry, that won't cut it either. It's just not the same thing at all. > > Regards, > > Thomas Hallgren > > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Mon, 23 Aug 2004, Joshua D. Drake wrote: > 1. Core -- Main database backend -- central approval/rejection > a. plCore -- controls the release/distribution/testing etc.. of the pl > languages > b. contribCore -- products that make it into contrib ya, its called moving those things not required in core, out of core :) What I've been fighting for for almost two years now :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Quoting Bruce Momjian : > Thomas Hallgren wrote: > > Marc, > > > Since I (and I don't believe anyone else on core) uses Java ... > > > shouldn't it be up to the developer of the PL/J* modules to do this? We > > > > can't weigh which one is better then the other, as we don't use it ... > > > > > Of course the contributors should supply as much of this material as > > possible. The point I'm trying to make is that there's often no > > incentive to do so, nor a good place to put it. > > What incentive do you want us to give? We don't have any. And if > someone does it, we will find a place for it. > > > > Also, how does someone support something that they don't use? Again, > > > that is the developer of PL/J*'s job to do, not ours ... > > > > > Again, I'm not trying to offload work from the contributors onto the > > members of core. This is about how things are perceived by the > > PostgreSQL customers. Of course the contributors must continue to > > support their products. If they don't, I'd expect the "supported" status > > to be dropped at some point. > > I think you want us to look more like a MySQL AB or Oracle company where > things are more bundled and blessed. It isn't going to happen with us > because we aren't a company, don't make money, and don't control anyone. > > This reminds me of the MySQL migration guy who didn't want to use a 3rd > party replicaiton solution. I really wanted to say he might be happier > with MySQL. I don't know if you're referring to me, but I was just expressing me and my company concern about using 3rd party solution. I don't have any intention of finding PostgreSQL's fault (and I'm not saying you accuse of that, because you don't). I think it's a great product, and as I've said, I used it personally before, and I loved it. The problem I'm having is that I'm coming from business point of view. And so I'd like to know what is the plan PostgreSQL team has for those 3rd party solution. We don't really want to use MySQL. But from what you tell me to use MySQL just because of my avoidance of 3rd party solution, then I think a lot of people will overlook that PostgreSQL is a good product. From the long discussion, I do now understand that PostgreSQL team would rather focus on the core. And I think Ben (bench@silentmedia.com) answer it well by saying that there's an opportunity of business (of gathering the core and 3rd party solutions into a package). That gives me the relief that at least there's somewhere we can turn to for support in packaging.
__________
Advertisement:
 | Mobilais telefons SAMSUNG SGH-P510 |
| ar automatisko atversanas mehanismu! |
| tikai Ls 217 |
| www.1a.lv |
jimworke@inbox.lv wrote: > I don't know if you're referring to me, but I was just expressing > me and my company concern about using 3rd party solution. I > don't have any intention of finding PostgreSQL's fault (and I'm > not saying you accuse of that, because you don't). I think it's > a great product, and as I've said, I used it personally before, > and I loved it. > > The problem I'm having is that I'm coming from business point > of view. And so I'd like to know what is the plan PostgreSQL > team has for those 3rd party solution. > > We don't really want to use MySQL. But from what you tell me > to use MySQL just because of my avoidance of 3rd party solution, > then I think a lot of people will overlook that PostgreSQL is > a good product. > > From the long discussion, I do now understand that PostgreSQL > team would rather focus on the core. And I think Ben > (bench@silentmedia.com) answer it well by saying that there's > an opportunity of business (of gathering the core and 3rd party > solutions into a package). That gives me the relief that at > least there's somewhere we can turn to for support in packaging. Yea, we are more dynamic and and less organized than companies. That is good and bad. Agreed companies can help to give a more organized front to our project, but underneath we will still be less organized than a company that hires guys to do things --- again good and bad. If we are too organized, we would look good and solid on the outside, but the vibrancy that makes us successful would be gone. Frankly, I think companies will understand that in years to come, but perhaps not right now. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Is this one more incarnation of the packaging, release-announce and what has to be CORE or not discussions? Well, the fact that the discussion is going on and on does indicate that the project "management" doesn't do a good job here. We have repeatedly stated that the core project doesn't have the time, resources or whatever to evaluate all those auxilliary projects and therefore we can't put together a list of recommendations. I think this true ... in part. The true part is that the core project (not the CORE team alone) does not have the resources to review or evaluate all this. We probably don't even have the skillset to make any educated guesses about it. But I would say this is true about every project I ever have been a member of or every job I have been in. Probably one of the outstanding abilities of the best managers I have ever worked for is "management by deligation". This does not mean to deligate work, but to deligate decisions. And then to go with that decision, accept it and to defend it. Just because we don't have the skillset ourselves cannot mean that we leave the PostgreSQL user community in a decision vacuum. I don't think anyone really likes to be responsible for decisions he didn't make. But I guess that is what we have to do because our continuous "we don't know, it's your choice, pick your own poison" is just not what anyone wants to hear. And interestingly it is what most of us do anyway. How many of us really have the skillset to make an educated decision about the exact implementation of PITR features, the best strategy for buffer replacement, how to start/stop/throttle background writing of dirty buffers or why and when xid's should get frozen or not? Honestly, I do not know the answers to most of the questions that have to be decided inside of the core server these days either because I don't have the skillset or because I didn't have the time to figure it all out myself. Does that mean that I will not have to defend the way we do savepoints tomorrow? Nope, I will have to live with it and carry that decision to shows and events and everywhere as if it was my own one. Now what is exactly the difference between those "core" feature decisions and the "auxiliary" or "3rd party" things? The fact that their code isn't part of our tarball is only an excuse for not making any recommendations. I don't care what type of admin tool the PostgreSQL community suggests for package maintainers to include in every standard installation of our database. I don't use any of them myself. But every single of them is certainly a lot better that our repeated *shrug*. If we need user- or community votings on this, then lets do them. Let us stop telling people that nothing is good enough to be recommended by the PostgreSQL team. It is not true. There are a lot of things and add on products out there that are. And if 70% of our users vote for "C", then putting that onto a recommenation list is certainly not the worst. Jan On 8/23/2004 5:25 PM, Bruce Momjian wrote: > As an example, who has the largest 8.0beta1 downloads? pginstaller. > And who controls that? The pginstaller project team. It has no > official relationship to anyone except it is a useful project and we > mention it in the release notes. > > --------------------------------------------------------------------------- > > Thomas Hallgren wrote: >> Marc G. Fournier wrote: >> >> > >> > As Tom (I believe) has stated, and both Bruce/I have said over and >> > over again ... this is nothing stop'ng a group of ppl starting up a >> > "bundled postgresql" project, and dedicating their time and effort >> > into building something up ... >> > >> > As Peter has stated, he had thought of this in the past, and felt it >> > was easier/better for the various OS distributions to do it on their >> > own ... >> > >> > In fact, Linux and FreeBSD *both* already deal with this in their >> > RPM/ports collections ... and, in fact, on the FreeBSD side, smaller >> > is better then larger, so that packager maintainers don't hvae to >> > download a 12Meg file to get a 1Meg port out of it ... >> > >> Bruce Momjian wrote: >> >> >We are not adverse to someone taking the core db code, adding other >> >stuff, and making a new super distribution. >> > >> > >> Your customers and many of your contributors would really like to see >> PostgreSQL become more then just the core backend. A Redhat bundle is >> great if your'e a Redhat user. If you are on another platform however, >> it's no good to you. And some bundle from "a group of ppl" or "someone"? >> No, sorry, that won't cut it either. It's just not the same thing at all. >> >> Regards, >> >> Thomas Hallgren >> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 7: don't forget to increase your free space map settings >> > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck <JanWieck@Yahoo.com> writes:
> How many of us really have the skillset to make an educated decision about
> the exact implementation of PITR features, the best strategy for buffer
> replacement, how to start/stop/throttle background writing of dirty
> buffers or why and when xid's should get frozen or not?
It's not necessary that we all do; it's only necessary that some of us
(preferably more than one, but at least one) know enough to make
reasonable choices on any one point.
> Now what is exactly the difference between those "core" feature
> decisions and the "auxiliary" or "3rd party" things?
The fact that there isn't *anyone* stepping up to do that investigation
or make those decisions. If someone steps up to the plate, I'll be glad
to give all the moral support we can. In the absence of someone
actually volunteering to do the work, this whole discussion is
pointless.
regards, tom lane
> a) More software can make use of your good name and reputation. That's rather dangerous, don't you think ? If PostgreSQL proper (eg the core server) wants to keep its good name it better make sure it is bundled with "good" "add-ons". And that would require precisely the additional workload that several core people have explained they must avoid in order to be able to focus on the core engine to keep its good reputation. So, unless people outside the core team take up the task it won't happen. And if they do - what's the difference to the current state of affairs ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
On 8/24/2004 12:02 AM, Tom Lane wrote: > Jan Wieck <JanWieck@Yahoo.com> writes: >> How many of us really have the skillset to make an educated decision about >> the exact implementation of PITR features, the best strategy for buffer >> replacement, how to start/stop/throttle background writing of dirty >> buffers or why and when xid's should get frozen or not? > > It's not necessary that we all do; it's only necessary that some of us > (preferably more than one, but at least one) know enough to make > reasonable choices on any one point. > >> Now what is exactly the difference between those "core" feature >> decisions and the "auxiliary" or "3rd party" things? > > The fact that there isn't *anyone* stepping up to do that investigation > or make those decisions. If someone steps up to the plate, I'll be glad > to give all the moral support we can. In the absence of someone > actually volunteering to do the work, this whole discussion is > pointless. That wasn't what I was talking about. We don't need someone to take another management position. We need to develop the ability to ask our -general and -hackers communities "what are the top 2 products of category foo in your opinion", take that without any in depth code review and sophisticated investigation and promote it. I want to get rid of the recommendations-vacuum. I don't care if we don't pick the ultimately best of everything that way. If there is a consensus of people who use these things, repeating their recommendation will seldom be bad advice. Those people have proven already that they can make good decisions, they do use PostgreSQL after all :-) All we need to do is ask them. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Thomas Hallgren <thhal@mailblocks.com> writes:
> ... My suggestion is not that you take on more work but
> rather that the comittee is allowed to grow and take on responsabilities
> and people beyond the developers of the core database.
Enlarging the core committee by the amount you seem to be thinking of
would transform it into something quite different than it is now
(in particular it would be too large to make decisions effectively,
IMHO). And I don't see that it actually accomplishes anything.
The real issue here is finding someone to do the work --- it's notable
that this thread has been going on for some time now and no one has
actually stepped up and volunteered to *do* anything. I think if there
were someone out there willing to do it, they could and would do it,
with or without core's blessing.
regards, tom lane
On Mon, 23 Aug 2004, Thomas Hallgren wrote: >>> In times when people download gigabytes of film and music using >>> BitTorrent, I think that's the least of our problems. But of course, the >>> distribution should be kept at a reasonable size. That's why I'd like a >>> better solution to replace the inferior one and to limit the number of >>> overlaps. >> >> >> At which time we are once more 'playing favorites' ... > > Sorry, but that one got right pass me. 'playing favorites'? your comment about 'limiting the number of overlaps' ... to do that, the one maintaining this package would have to decide that 'PL/J' is better then 'PL/Java' (or vice versa) ... if maintainer doesn't know/use Java, then, what, each group of developer then 'lobbies' the maintainer for inclusion? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 23 Aug 2004, Thomas Hallgren wrote: > Tom Lane wrote: > >> Enlarging the core committee by the amount you seem to be thinking of >> would transform it into something quite different than it is now >> (in particular it would be too large to make decisions effectively, >> IMHO). >> >> > I can relate to that. Lean and mean is good. So pehaps the core committee > should not be enlarged. Instead, another committee should be established for > this purpose that work closely together with the core committee (perhaps > cross staffed to some extent). You are almost there ... now, go that one extra step and you have "a side project whose goal is to take the core server and bundle it with 3rd party apps to provide a complete RDBMS solution" ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Tom Lane wrote: >Enlarging the core committee by the amount you seem to be thinking of >would transform it into something quite different than it is now >(in particular it would be too large to make decisions effectively, >IMHO). > > > I can relate to that. Lean and mean is good. So pehaps the core committee should not be enlarged. Instead, another committee should be established for this purpose that work closely together with the core committee (perhaps cross staffed to some extent). >The real issue here is finding someone to do the work --- it's notable >that this thread has been going on for some time now and no one has >actually stepped up and volunteered to *do* anything. I think if there >were someone out there willing to do it, they could and would do it, >with or without core's blessing. > > > Given a financial scenario that would make it possible, I'd love to help with this. My current employment however has no connection to PostgreSQL. Regards, Thomas Hallgren
On Tue, 24 Aug 2004, Jan Wieck wrote: > I want to get rid of the recommendations-vacuum. I don't care if we > don't pick the ultimately best of everything that way. If there is a > consensus of people who use these things, repeating their recommendation > will seldom be bad advice. Those people have proven already that they > can make good decisions, they do use PostgreSQL after all :-) Shouldn't some sort of automated voting system be created first? With the ability to 'add software' and then 'vote on it'? Maybe have some sort of login procedure such that someone could later login and change their vote? ie something better came along ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Karsten Hilbert wrote: >>a) More software can make use of your good name and reputation. > > That's rather dangerous, don't you think ? If PostgreSQL > proper (eg the core server) wants to keep its good name it > better make sure it is bundled with "good" "add-ons". And that > would require precisely the additional workload that several > core people have explained they must avoid in order to be able > to focus on the core engine to keep its good reputation. So, > unless people outside the core team take up the task it won't > happen. And if they do - what's the difference to the current > state of affairs ? > I see you point and I don't disagree. But let me give you a different view. When I look at the current state of affairs, I see a PostgreSQL name that, in spite of very skilled people, great technology, a very vibrant community, and IMO a golden opportunity, is held back by a fear (well grounded, no doubt) that growth will increase the workload and thus make it harder to maintain the core engine. I'm not an advocate of commercial packaging, nor packaging performed by "outsiders" and I don't think packages bundled with operating systems is a great idea either. I'm a fan of free open source and I think the way to archive growth is to appeal to more sponsors. More sponsors equals more resources. More resources, if handled correctly, could both make PostgreSQL grow *and* lessen the workload for the core developers. I really like Jan Wiecks suggestion. To me that sounds like the way to get started. Recommended add-ons will feel a lot "safer" to the end users and it will give some perception of growth. I'd like to help out and I'm perhaps able to put in a couple of hours a week. Maybe there's more people out there that would like to help? If not for any other cause, then maybe to promote their own product. In so, we need to be coordinated. Preferably by someone from "within". Regards, Thomas Hallgren
On Tue, 24 Aug 2004, Thomas Hallgren wrote: > I really like Jan Wiecks suggestion. To me that sounds like the way to > get started. Recommended add-ons will feel a lot "safer" to the end > users and it will give some perception of growth. I'd like to help out > and I'm perhaps able to put in a couple of hours a week. Maybe there's > more people out there that would like to help? If not for any other > cause, then maybe to promote their own product. In so, we need to be > coordinated. Preferably by someone from "within". Well, since you seem to have the desire and time to spearhead this, let us know when you have something for us to look at and evaluate ... thank you for volunteering :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
In an attempt to throw the authorities off his trail, tgl@sss.pgh.pa.us (Tom Lane) transmitted:
> Thomas Hallgren <thhal@mailblocks.com> writes:
>> ... My suggestion is not that you take on more work but
>> rather that the comittee is allowed to grow and take on responsabilities
>> and people beyond the developers of the core database.
>
> Enlarging the core committee by the amount you seem to be thinking of
> would transform it into something quite different than it is now
> (in particular it would be too large to make decisions effectively,
> IMHO). And I don't see that it actually accomplishes anything.
>
> The real issue here is finding someone to do the work --- it's notable
> that this thread has been going on for some time now and no one has
> actually stepped up and volunteered to *do* anything. I think if there
> were someone out there willing to do it, they could and would do it,
> with or without core's blessing.
It seems to me that some vital components have already been set up,
considering:
a) pgxs provides a "build environment" to make it easier to add in
"third party extensions" without each of them having to have its
own full PG source tree.
b) PGFoundry is getting set up as a hopefully-decent place to host
things that would be likely to fit into that "second tier" of
"Extensions that ought to be ubiquitous."
Those can also play off against each other; for an extension to become
"ubiquitous," it is only reasonable for its developers to improve the
builds to make them play well with pgxs.
The way I can see this head is for there to be a significant
population of projects on PGFoundry that, by virtue of using pgxs,
become as easy to add in as most of the contrib items are now, and
perhaps roughly as easy as the average BSD Port.
I did both a Solaris and AIX build today, and threw in a whole barrel
of contrib modules via the simple statement:
for module in pg_autovacuum oid2name pgstattuple pgcrypt [and more...] ; do
cd $module
make clean
make install
cd ..
done
If there were 35 projects on PGFoundry set up in much this way,
perhaps more in the BSD Ports style, where I can pull down a tarball
with 35 directories, and then set things up...
$ export http_proxy=http://cache.myhost.example.info:3128/
$ exPGCONFIG=`/usr/local/lib/pgsql801/bin/pg_config --configure`
$ PGDEPLOY=/tmp/pgfoundry
$ cd /usr/local/src/pgfoundry
$ for module in PGF*; do
cd $module; make install; cd ..
done
The "make install" would download the _real_ sources, via the
requested HTTP proxy, run "make" on each one, using the PostgreSQL
backend configuration specified in $PGCONFIG, and then
That's the sort of thing that _also_ makes it pretty easy for package
management folk to bundle it up ready for integration tests. There
are tools for both Red Hat-style RPM's and Debian .deb's that
specifically pull modules from Perl's CPAN site, by name, and then
bundle them into packages.
This doesn't "magically" solve all systems integration problems, but
it sure seems likely to go a long way to help.
--
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/advocacy.html
Users should cultivate an ability to make the simplest molehill into a
mountain by finding controversial interpretations of innocuous
sounding statements that the sender never intended or imagined.
-- from the Symbolics Guidelines for Sending Mail
Marc G. Fournier wrote: >> Sorry, but that one got right pass me. 'playing favorites'? > > > your comment about 'limiting the number of overlaps' ... to do that, > the one maintaining this package would have to decide that 'PL/J' is > better then 'PL/Java' (or vice versa) ... if maintainer doesn't > know/use Java, then, what, each group of developer then 'lobbies' the > maintainer for inclusion? If they where considered overlapping solutions there would have to be a vote, but, as I explained earlier in this thread, that's not necessarily the case Regards, Thomas Hallgren
Christopher, > > > It seems to me that some vital components have already been set up, > considering: > > a) pgxs provides a "build environment" to make it easier to add in > "third party extensions" without each of them having to have its > own full PG source tree. > > b) PGFoundry is getting set up as a hopefully-decent place to host > things that would be likely to fit into that "second tier" of > "Extensions that ought to be ubiquitous." > > Those can also play off against each other; for an extension to become > "ubiquitous," it is only reasonable for its developers to improve the > builds to make them play well with pgxs. > > The way I can see this head is for there to be a significant > population of projects on PGFoundry that, by virtue of using pgxs, > become as easy to add in as most of the contrib items are now, and > perhaps roughly as easy as the average BSD Port. > If this whas combined with Jan W. suggestion (community votes to create recommendations) it would be very close to what I had in mind in the first place. A project could be hosted on PGFoundry where the "verify" process could be explained, i.e. 1. your project must be pgxs compatible. 2. it must be hosted on pgFoundry. 3. it must have automatic regression testing built in (perhaps this is part of #1). 4. documentation must follow some guidelines so that it is easy to combine it with other docs. 5. someone must suggest it as a candidate for inclusion and give a good motivation. 6. there's a voting period and a minimum number of votes. 7. if the votes are in your favor, your project will be part of the supported configurations and you will be asked to participate in the integration work. This project could also host the voting mechanism and the supported configurations. My Concerns: Who is behind PGFoundry? Is performance ok now :-) This project might be perceived as a thirdparty add-on and thus, fail its purpose. The steering committee must stand behind this officially. Will you? What's your opinion about the suggestion? Any ideas what the project should be named? Regards, Thomas Hallgren