Slashdot Mirror
Sun Announces Support for PostgreSQL
jadavis writes "Sun announces 24x7 support for PostgreSQL on Solaris 10. From the article: 'Today Sun announced that it will be integrating the Postgres open source data base into the Solaris 10 OS and providing world-wide 24x7 support for customers who wish to develop and deploy open source database solutions into their enterprise environments. Sun is working with the PostgresSQL community to take advantage of the advanced technologies in the Solaris 10 OS, such as Predictive Self-Healing, Solaris Containers and Solaris Dynamic Tracing (DTrace).'"
What's next, will solaris understand cursor keys? Ship with BASH? What's the world comming to?
Solaris has shipped with bash for quite a while now...
A house divided against itself cannot stand.
Who uses Solaris 10?
== Jez ==
Do you miss Firefox? Try Pale Moon.
I believe that Oracle is most often installed on Sun Solaris servers, so I am wondering whether Oracle should be worried by this announcement from Sun to offer extensive support for PostgreSQL. It seems that open source databases (Firebird, MySQL, PostgreSQL) are becoming greater threat to commercial ones like Oracle and DB2. Anyway, I think that PostgreSQL is great fit for Sun, because they will have relatively low development costs, but will nevertheless enable them to sell more hardware.
You are missing the point. If articles had to represent some demographic then we'd all be reading articles about IE and Windows (to slightly paraphrase your comment). I don't use Solaris but I still enjoy the article.
It is exciting news for Postgres users. The prospect of Sun coming aboard and actually contributing is great. And 24x7 support will get more people aboard.
hmm...they must've (must have - that bothers me too ;) ) changed their pricing. Part of the reason we switched to Dell years ago, was that for the price of the support on our Sun machine, we could buy a whole new Dell machine every year....
;)
Besides - With Sun we were paying all that money and never had to make use of it - with Dell, you regularly get to feel like you're getting something for your support money
Advanced users are users too!
that's outdated. someone bought 1 million hours of their grid already.
Actually, they don't. What is going on, is a inside fight.
There is a group there that fears MS (rightly so). They think that dealing with MS is dealing with the devil. They really want to crush them at all costs. This group pushes Sun towards the OSS path. The group is also responsible for the approach with OpenOffice as well as Java. Problem is, that MS won the desktop sometime ago, and is entrenched. Taking it back is a very difficult thing to do. As to server space, They do not see MS is taking from them (probably right). That group is helping linux.
The other group sees Linux taking from them (rightly so). Linux has been eating up server space. They are taking away from Solaris. This group did open solaris as a way of winning very lucrative support contracts and hopefully to sell hardware. One of the keys here is to try and make Solaris more like Linux. So they are trying to adopt a number of OSS and claim that they deserve the OSS worlds support. What is interesting is that they are starting to support BSD (I am not sure if they are looking to take it over or as support against Linux; more like a long-term trojan horse).
So what does it mean? That Sun is like any other large firm. There are multiple fractions playing games in house and McNeally lets it go.
I prefer the "u" in honour as it seems to be missing these days.
Opening up? Things to come?
Sun has been one of the biggest commercial open source supporters for years now. Probably only surpassed by IBM and the Linux companies ( RedHat and Suse, Linux is their core business after all ).
Millions to buy StarOffice, millions to setup and run OO.org and OpenDocument development, marketing, promoting OpenDocument. Releasing packages like GridEngine, etc. http://www.sunsource.net/. Years of shipping and support opensource applications to companies that would never have used it otherwise.
Back when I was a network admin, we got a whole lot of GNU software in the system by first showing superiors that Sun endorsed those packages and actually provided solaris binaries.
Sun's main issue is PR, I suspect. When IBM does something good, it makes sure everyone knows. But that doesn't seem to be McNealy's style...
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Our shop is mostly Solaris (8) and RHEL with Oracle 9i. We're currently looking at upgrading our Solaris boxes to Solaris 10.
The problem? Oracle 9i is not supported on Solaris 10. It's supported on RHEL and earlier versions of Solaris.
So at the moment, it's not doable for us. But from the tinkering I've done with Solaris 10, it's actually pretty cool. I've got it running on an Ultra 10 under my desk and have been evaluating ot for a couple of months now. I'll tell you it's much lighter than previous Solaris versions (well, 7 on. 2.6 was pretty zippy in comparison later versions).
- ditch the forte crap and vendor lockin scheme
x .xml) on Tuesday. It's completely free to use unless you want support. They also ship lots of GNU tools included in Solaris (under /usr/sfw) in case you would rather use them.
) is up to five times faster than UltraSPARC-III and up to twice as fast as the initial UltraSPARC-IV. And the UltraSPARC T1 chip (code-name Niagara http://www.sun.com/processors/UltraSPARC-T1/index. xml) delivers incredible throughput (in my testing, often faster than a V40z with four Opteron 850 CPUs) while consuming much less power and generating much less heat than any other chip delivering anything close to the same performance and throughput.
Done. Sun released Studio 11 (http://www.sun.com/software/products/studio/inde
- ultrasparc performance is terrible. Address it.
Done. The UltraSPARC-IV+ chip (http://www.sun.com/processors/UltraSPARC-IVplus/
- get the X11 libraries and headers fixed - completely
Done. Solaris 10 (at least on X86) uses the Xorg implementation. The previous Xsun implementation is also available if you need it, though.
- Get ldap working without so many support applications
I can't say that I understand this one. Sun's Directory Server is the best performing and most scalable server available. It's very in-line with the standards so any LDAPv3-compliant application should work with it just fine. It is the preferred directory for use with most commercial LDAP-enabled applications.
- make your platform work better with OSS software (eg: gcc)
What else needs to be done in this area? Solaris 10 ships with a lot of OSS software, including GCC, and Sun makes a lot of additional OSS software available on the Companion CD (http://www.sun.com/software/solaris/freeware/). If that's not enough, you can use the SunFreeware (http://www.sunfreeware.com/) or Blastwave (http://www.blastwave.org/) collections to get what you need.
Um... you are trying to equate the general rabble with those of us that have actually supported production databases. That's absurd and dishonest of course.
We're not some "hegemony". We're a very collection of factions with conflicting experiences , sensibilities and interests.
I would love Postgres to knock the wind out of Oracle. A price cut would be very handy. I coulud spend some money on hardware rather than sending it all to Ellison.
A Pirate and a Puritan look the same on a balance sheet.
Actually there is completely no point whatsoever in setting up MySQL as multiuser in a simple web hosting environment. You may as well just tell everyone to use "root" and no password.
Yes, you think that's insecure, but the truth of the matter is that giving individual users their own MySQL username and password does not make it any less insecure. I am of the opinion that it's better not to lull people into a false sense of security: if they can see how sharp the blade is, they will be more careful when using a powerful tool.
That's a really bad idea IMO.
Fact: it's trivial for any user with an account on a box to read any other user's files, even in their cgi-bin, since they must necessarily all be visible to the Apache daemon user {www-data on Debian systems}.
That's not a fact, but it is the sign the server hasn't been configured very well.
The only way around this is for every user to run their own instance of the Apache server as themself, on a different non-privileged port; and to have a transparent proxy on port 80 that redirects requests to the appropriate port based on the host name.
Shared web hosting platforms should really be using some implementation of per-customer compartmentalisation at the OS level if the users are allowed SSH access, or to run CGI's. Solaris 10 supports this natively, there are at least two separate native implementations of something very similar for Linux, Windows 2003 even supports this to some degree I gather (though not to quite the same extent) and then there are tools like VMWare.
Of course, running your MySQL server on an entirely separate hardware from your web server is also a Good Thing(TM), especially when someone manages to (most likely inadvertently) DoS your SQL server.
However, failing that, any web server used by multiple customers to run CGI's should at the very least be configured to use something like suexec, which has been a standard feature of Apache for about 8 years or so.
Using suexec (or gsexec, or cgwrap, or similar tool as appropriate for whatever web server your using) is precisely intended to prevent CGI's running as one user from accessing or modifying files (including other CGI's) that belong to another user.
I'm glad to see this. It seems MySQL gets way too much attention these days in the open source community. Not that it is a junky database server or anything, but I've been using Postgres for 4 years now and the system simply amazes me with every new release. It's power, ease of setup & maintenence and incredible stability (as far as I see it) is simply unmatched in the "free" database world. I would take it any day over an MSSQL Server. It's nice to see a company like Sun decide to include it in it's system and support it.
changing the block size used by the transaction log is something that should only be done by experts
Why? Doesn't this merely increase or decrease the sized of the TL before it recycles? As a n00b PostgreSQL administrator (non production as of yet) I am always on the look-out for information I may have overlooked.
I doubled the TL block size because I wanted to obtain a lengthy historical record. This was completed in the config file so the recompilation issue does not apply but now I am curious whether or not this will have unintended consequences. I have noticed no negative consequences but have not yet benchmarked very extensively.
From this angle, I would expect that you can get "normal" Debian binaries to run, as long as your Debian is reasonably close to whatever Sun will provide in that "Red Hat container" (Probably AS 4.0 compatibility, what else could that be?). Something Debian which just brings its own private configuration files, or does not have any configuration files.
But something which tries to start certain services available on Debian, tries to reconfigure those services, installs boottime scripts and so on I would expect not to work out of the box. If its just one or two scripts which need to be adapted, that might not be too difficult to get to run with a little bit of effort. Or somebody else such as the Debian/Solaris project might have done that already.
Whereas something which tries to start non-exotic services available on Red Hat, tries to reconfigure those services the way they are configured on Red Rat, installs boottime scripts and so on I would hope to frequently work inside of that "Red Hat container".
Thomas
But the original poster was talking about having complex _PHP_ stored procedures to do stuff - see the last two paragraphs.
Well, I think that is a stupid idea but not for reasons of performance.
MySQL devs are always thinking of one db per app and one app per db. When you do things this way, it doesn't really matter *where* you put the code. But most db's don't evolve to be a single app db. Often you are running multiple apps against that DB after a while.
And in these cases, it is important to cleanly separate what is app specific and what is multi-app. Multi-app functions should be placed in the DB for reasons pertaining to central management. Single-app functions should *not* reside in the DB. Multi-app extratransactional functions (i.e functions outside the db that must be performed after the transaction successfully commits) should be done with a combination architecture (special client, queue table, NOTIFY).
As for if it can be done with Slony, sure. Slony is a master/slave async replication solution. When combined with PgPool, it is possible to route writing operations dynamically to the master. So any functions you want to set up can be used via Slony and PgPool. However, in this case, I think it would be a maintenance nightmare. Indeed if you wanted this sort of architecture, I would suggest a different approach:
1) Set up "middleware" PostgreSQL servers running DBI-Link against a PGPool setup with Slony (for load balancing/replication). Install PL/PHP on them.
2) Set up all your PL/PHP functions on these middleware servers. This way you can separate you DB's, your replication and load balancing, and your web front-end.
You add a little bit of latency, but in the end you gain a whole lot of maintainability and scalability. See, in this case you could use PostgreSQL as a middleware technology....
LedgerSMB: Open source Accounting/ERP