Well, I kinda expected someone to point this out. Consider that a somehow hidden irony of my post
So yes, I'm well aware that there are 50 states within US, although I could probably name only ~30 of them, and that the laws may be very different among them.
I'm really wondering why not to circumvent this in some way. Say moving Groklaw to a country that is "out of reach" for the US government (not sure if there's one).
A more general question is what are a viable alternatives to e-mail. Everyone talks about how it's impossible to keep privacy with current email, because even if you encrypt the payload the headers are still plaintext, but I haven't seen anything solving this issue so far. It shouldn't be that hard, I guess - after all the headers don't really matter to the MTAs, except for the "to" so moving them to encrypted payload should not be a big issue (but maybe I'm naive).
If there's one thing that really annoys me on people from US, it's talking about Europeans. There's no such thing (no matter how much the European Union denies that). Europe is a geographical group of ~50 countries that are very (very very) different in all aspects. Did you know that Azerbaijan, Belarus or Georgia are European countries? (I have nothing against those countries, I'm just trying to explain that assuming all countries are like France, UK or Germany is pretty much nonsense). It's like talking about Americans when actually talking about people from Brazil, Argentina, Mexico and Canada because thay all live on continents with "America" in the name.
Even this "We are the best!" bullshit is present only in some of the countries. That does not mean the people in the other countries are not proud of their country, they just don't treat the others as crap. I'd bet it works the same way in the US, btw - most people genuiely proud of their country/state and a few nationalist loonies (which get the most in foreign news, so the impression is quite distorted).
There's one difference, though. The Swiss are right.
The nastiest (security) issues I've stumbled upon usually happened at the boundary of multiple components (developed by various teams and therefore multiple individuals). None of them was really the single offender, it was mostly about incorrect assumptions / pieces reimplemented through the lifetime / specifications not detailed enough (well, is there such thing as a complete specification?). And those are the most difficult issues to debug / identify.
So "fire the guy who wrote the offending code" may not be as simple as it sounds. And even the best developers I know do a mistake from time to time.
Good work, Facebook! Kinda resembles what happened at GitHub ~18 months ago: http://www.zdnet.com/blog/security/how-github-handled-getting-hacked/10473
If someone from Facebook reads this, and it's TL;DR; here are the next steps:
#1 apologize to the guy, acknowledge he reported the issue twice
#2 reinstate the account and pay him his reward
#3 fix the damn issue
Stored procedures can be very efficient sometimes, but often, they just add additional load to the DBMS server that could have been distributed among application servers...
This, however, is mostly nonsense. It's true that stored procedures may add load to the DBMS, however it's equally true they may significantly reduce the overhead. What's more efficient - transferring 1M rows to an application server and handle it there (often submitting the result back to the DBMS as a parameter for the next query), or just process it locally within a stored procedure? Not to mention that the "application servers" usually manipulate the data using languages that are very poor match for such operations (which is basically everything except for SQL).
The first line of defense against loading the DBMS server is to start with intelligent queries and organization. Logic should avoid chewing through millions of rows in a programmed manner no matter which machine the chewing is done on. The DBMS is optimized for information retrieval and updating, and stored procedures can potentially interfere with that optimization. So rule 1 is to reduce what gets acted on. If you do that, the relative overhead of pushing it out to client machines is less of an issue and even the fact that the client machines are probably going to be less powerful won't matter as much, because there will typically be more of them to share the computing load. Because they're also likely to be less expensive machines, the next cost per computation is often lower as well if the DB server's CPUs are being efficiently used.
Intelligent queries and organization - sure, no argument here. However there are cases when you really need to chew through millions of rows, and doing that in SQL directly without imperative code is nearly impossible. And I wasn't saying that it's a good idea to replace queries with stored procedures - that would be the dumbest thing in a relational database (which is exactly about running queries). If you can write a query solving your problem well, don't write procedures. No doubt about that.
I think we're both speaking about different cases, though, so I'm missing your points and you're missing mine. I'll illustrate my reasoning by an example of an actual project that I had in mind
About 2 or 3 years ago I was asked to help with a project in serious troubles - many things went wrong during the development, from starting the development on MySQL+Tomcat and switching to Oracle+Jboss, to heavy usage of Hibernate mixed with crazy "optimized" SQL queries.
The largest problem was that they needed to monthly balancing (it was a system for managing retail network). The business process behind this is rather complex, and the process steps need to work with large sets of rows (chew through all the transactions for all sales, salesmen, branch
So the developers decided to do this on the application server, and to mess it up as much as possible, they used the Hibernate definitions optimized for the front-end (lazy fetches everywhere,
This is the exact place where stored procedures are a good match - with a bit of PL/SQL and Oracle magic, the whole closing was running in 3 minutes, no load on the app server, light load on the database.
If you had poor development practice (and the fact that you are saying that "stored procedure code is also not as likely to be version-controlled" strongly suggests this), then sure - it might be nightmare. But it's not a fault of stored procedures but purely your fault.
I'm not going to accept fault on that, because I don't do stored procedures except in cases of compelling need. But whereas applications in C# and Java are typically managed by an IDE and bound to a Version Control System, every database system I've had to clean up after basically had someone editing the procedure in the equivalent of Windows Notepad and jamming the code straight into the database with no local project management at all. A few DBMS's have the ability to retrieve earlier generations of database objects, but it's the exception rather than the rule.
In short, I'm making my recommendations based on what I commonly come in and find has been going on, not on what would be the case in an ideal world.
Which is exactly what I was speaking about
Let's not get into bashing Hibernate here. I'll just say that the only project where I've seen reasonably efficient and working usage of Hibernate was the one project with the highest number of people actually knowing SQL well. Which is exactly what most ORM promises you won't need
Sure, you don't need to shut down the database to do a backup. Just call pg_start_backup, do whatever copy you want (copy of the files, LVM snapshot,
Opening a case
I'm not sure about the VM thing, but as they do offer "vFabric Postgres" [http://www.vmware.com/products/application-platform/vfabric-postgres/overview.html] and that VMWare is generally a PostgreSQL-friendly company, I'd say it might be certified.
Never heard the phrase "You've been Oracled" before?
Well, that's many questions in one post, so let's discuss that one by one
1) OLTP RDBMS with 2000 concurrent users, 200 transactions per second on 5TB of data
It's really difficult to judge without more detailed info. I've seen such workloads on a single PostgreSQL machine - grab a machine with plenty of cores, say, a 32-core (64 with HT) R820 from Dell, stuff it with RAM, spinners for WAL and SSD for data, and you're done. It depends on what a "transaction" is actually doing, but let's ignore that. Actually you'll need this 3x for two standby machines, and a place for the storing WAL. You can use one standby for failover, the other one for long reporting queries, etc.
The 24x7x354 part is tricky - you can't do that with plain PostgreSQL, as even a hot standby means a short outage / reconnect during the outage. So you'll have to engineer the application accordingly - in case the master is gone, search for the new master and reconnect. Not a big deal, IMHO, but I don't want this to look like I'm playing down this deficiency.
If you want something more automatic, look at pgpool-II, or maybe Postgres-R and Postgres-XC. pgpool-II runs on top of PostgreSQL, the other two are forks.
2) COTS
Well, this may be true, although a COTS software that already supports multiple databases is usually simple to port to PostgreSQL. The problem here is that this is a circle - the company developing the software doesn't see any demand because the companies are not requesting PostgreSQL support. But this is changing.
Hints are a topic that appears frequently in discussions like this. I personally am grateful there's no such thing. However once you're stuck with Hibernate, you're hosed anyway.
3) Complex things
Well Oracle certainly gives you a way of doing complex things in a very complex way - no doubt about that. It's true that PostgreSQL doesn't have all the features built-in, however many can be implemented using third-party tools (e.g. pgpool-II, already mentioned) in a reasonably simple way.
4) Oracle people are the easiest to buy
I've had OCP in the application development (not sure if it's still valid), I know developers who went through the same tests etc. Frankly, it's not worth the paper the certificate is printed on. All it gives you is a proof the developer memorized some freaky procedure names and went through a test. It gives you exactly no idea if the developer is able to design a reasonable schema. It's way easier to just hire good developers and give them guidance and a few weeks to learn
And there are many (competing) companies providing PostgreSQL support, not a single corporate entity controlling the whole support chain.
Another thing is that sooner or later you're going to run into an issue that your experts don't know. With Oracle you have no access to the actual developers, so they can't answer your questions, you can't show them suspected bugs etc. I've had quite good experience with the web forums at oracle.com, but once you have to contact the actual support, it's pure bureaucratic madness.
5) I haven't noticed any en mass migration
Sadly many of these migrations are covered by strict NDA
6) Finally
All that said, although I'm not unbiased (as I'm participating in the PostgreSQL development), I'm far from saying "PostgreSQL is the answer to everything." There will always be cases where sticking with Oracle is the right choice - either it's cheaper, there's a feature you can't live without or something else.
Well, he's either kidding or he never installed Oracle using their Universal Installer.
It's difficult to compare the optimizers, because Oracle has parallel queries and some other features that complicate the optimizer considerably, but I've run into some very nasty issues with it in the recent versions I've been working with (10g and newer), from crazy plans to serious crashes. Never had the same issues with PostgreSQL. Obviously, both optimizers share the same weaknesses - like give them conditions on correlated columns and the estimates are going to be way off, possibly resulting in poor plan.
One thing that frequently shoots in the developer's face on Oracle is that the stats are not collected based on the activity, but you have to setup this as part of a maintenance window. Well, good bless autovacuum.
So you can prove that? Because when a company says "we have a process for that " it's often equivalent to a cluster-fuck in the future.
I can't really imagine anything more secure that the transparent development model used by PostgreSQL - you can see all the decisions in the mailing list, you can comment whatever you want, you can ask questions about supposed issues, you can see all the individual commits etc. And many people actually do that, so this is an example of a project where the "many eyeball theory" actually works. Can you do the same with Oracle, or do you simply trust to the corporation because they said so?
It's not that long ago when a serious security vulnerability was discovered in PostgreSQL, and in retrospect I think it was handled well (and the next feature will be handled even better). For more details see http://www.postgresql.org/support/security/
Well, that's certainly true. The reason is that PostgreSQL is not meant to be a drop-in replacement for Oracle (although many use it for this purpose), but an independently developed product.
There are many possible features that are not implemented in PostgreSQL (yet), or not to the degree available in Oracle. Examples might be partitioning, parallel queries,
BTW there already are products based on PostgreSQL that might be interesting for some RAC users - Postgres-R [http://www.postgres-r.org/] and Postgres-XC [http://postgres-xc.sourceforge.net/].
Things are not as simple as they seems at first. - Edward Thorp
