Slashdot Mirror
.org TLD Now Runs on PostgreSQL
johnnyb writes "The .org domain, which has long run on Oracle systems, is now being transferred to a PostgreSQL system. I guess we can now dispel the "untested in mission-critical applications" myth."
← Back to Stories (view on slashdot.org)
.ca runs on MS-DOS running some home brew DB that is just a bunch of batch files
-- OMFG = Oh My Floatse Goatse
Not true! I know someone who got fired for choosing oracle, then being unable to properly implement it.
Now we get to see how PostgreSQL handles those 98 % of wasted inquiries from DNS servers that don't know .elvis is not a TLD.
It's Christmas everyday with BitTorrent.
Because they don't take context or purpose into account at all. There are things that Postress may be better for and things that Oracle certainly shines at. I mean, hell, I love MySQL, too, but I wouldn't want to use it as the backend for _my_ system. Not that the others are hollisticaly "bad", it's just that Oracle is the most appropriate for this situation.
What's a TLD doing with a database? Making ridiculous numbers of extremely lightweight queries, and managing redundancy. That's not necessarily the same thing that everybody wants an "enterprise class" "tested" database to do for "mission critical" tasks.
:Wq
Not an editor command: Wq
I hope computerworld isn't running on PostgreSQL!
I'm much funnier now that I'm a subscriber.
All they need is netcat, shell scripts and grep.
Trolling is a art,
Verisign runs the shared registry with Oracle, but the registrar-specific data was and still is stored using Ingres.
No, it simply means that its going to be tested in a larger environment and if it does well then they get to party and say "woohoo it worked!" and if it flops they're all gonna feel really stupid. It doesnt mean its stable at all. The common practice of paraphrasing "LOOK!! Someone is using our product so it MUST work perfectly." is actually quite disturbing.
I had the misfortune of dealing with oracle tech support team once and I can say I am not surprised the ".org" domain has shifted to PG.
The DB was locking up when trying to retrieve data from a large table (>10 M rows) using a very complex query.The oracle guys kept suggesting that reduce the size of the table.
Now seriously is that a valid option ? Hey man , I have a million bucks in my acct. and i can't withdraw from the ATM ??
Just delete some of it and then try again ?
Or the most common answer from Oracle tech team is "we know its a problem but we will not fix it in this release. Just buy the next version if you want it fixed ?
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
I don't think the issue is that PostgreSQL will crunch data as well as Oracle. It's just that PostgreSQL has always had an undeserved reputation as "the database to use when you can't afford a REAL database", when actually it's a very robust and secure system that can compete quite well with commercial systems.
I'd really like to see some serious tests done with PostgreSQL. Database systems, especially Oracle, can be an expensive part of a datacenter. Considering that with Linux/PostgreSQL your only cost is hardware/support, it may very well scale more cost effectively than Oracle.
There's currently way too much marketing and FUD to get a real idea how these systems compare though.
If it breaks they can just go to postgresql.org to get updates and.... oh wait.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
I was a designer of the system that runs .nz (New Zealand), which is also based around PostgreSQL, running on three replicated back-end application servers.
The system was developed in mod Perl and went live on October 14th 2002.
The plan is to release this (including client software) under the GPL after a stabilisation period.
Competency isnt the issue here. I am assuming that whoever the actual developer of the fix is, that they will be extremely competent in fixing the problem. With an external entity, contractual terms of delivery will twist their arms into fixing severity 1 problems with the urgency that they deserve regardless of whether the fix is the best possible coding / architectural solution for the overall Postgres project. With an internal entity, the pressure will be less on them because if management threatens to "chop the head off" because of trying to do the "right thing" instead of just fixing the problem, they will have to stop and consider that they are damaging their own organization. It is always easier for management to be brutal with external entities rather than one of their own.
There is no such thing as luck. Luck is nothing but an absence of bad luck.
...that the entire O'Reilly Practical PostgreSQL book was put online?
;) Looks like it is time to revisit postgres, especially for some db-agnostic PEAR apps I'm building. For me, it's the subselects that really make it worth the effort.
I've spent so much time lately in the (relatively) flat-table world of MySQL that I had forgotten about inherited tables, subselects, constraints in table definitions, and oh yes, vacuuming.
http://tinyurl.com/4ny52
The real problem with Postgresql, however, is that if you are doing lots of updates where the keys increase forever, the index files grow forever. You can, of course, drop and recreate them (which we do in a cron job), but in a real 24/7 environment you've got a real problem when your queries all turn into table-scans because the indexes aren't built yet.
Here is some more information (seeIndex Maintenance? )
The only option I know if is to have two sets of tables and swap between them.
-- ac at work
The transition details can be found on the Public Interest Registry's Homepage. In short, they'll close the registry at 14:00 UTC tomorrow, transfer to Afilias's systems, and reopen the registrations on Sunday at 23:00 UTC.
If I here those words again, I think my head will explode. I don't remember anyone saying to use a wrench for a hammer if you have both. When people argue these things, they are argueing that a tool is the right tool for a job. PostgreSQL is being argued to be a tool that can be used for enterprise jobs. Either confront that or not, don't just state the obvious. No one said PostgreSQL is the only database to use.
I here this everytime a programming language is mentioned too. Either say Java can't do what perl can, or Java is slower than perl and back those up. Don't say Java is good and Perl is good because everyone knows that.
I don't mean to take my frustrations out on you poor poster, it's just high time people realize that this is like argueing philips or flat-head. It should be a poll option because it's preference, not because there ever is a right or wrong database for a job. It's a choice. After this has been going for a while without problems, we can then proceed to choose PostgreSQL to save money or because we like it better than Oracle or DB2.
It's as annoying as:
1: In soviet russia, Vi>Emacs
2: ?
3: goatse.cx, "MOD PARENT UP"
Yes, you are wrong, as of PostgreSQL 7.2 VACUUM can run without locking the table completely.
Garbage collection is a problem every database faces. Due to ACID requirements it is pretty much (absolutely?) impossible to run a database that updates rows without having multiple versions of the same row on disk at some time during the operation. So at some point in time you have to get rid of that duplicate. You can choose to do that after commit of a transaction (or the last transaction for which the row is still visible), but that would potentially make every transaction slower. So in PostgreSQL the choice was made to do this at an administrator determined moment (and I presume that choice also was the easy one).
In older versions of PostgreSQL VACUUM would lock the entire table and physically force all the valid rows to be rewritten consecutively and then reclaim the space at the end. This mode is still available as VACUUM FULL, but nowadays there is a new mode (sometimes called lazy vacuum) that only marks space safe to be overwritten. Subsequent updates/inserts will overwrite it eventually.
Regular running of this command will eventually lead to some steady state where there is some x% of bloat in the table, but there is no significant amount of locking required.
Because...
Ok. I think I figured it out.
.CA
.COM
.ORG?
Microsoft puts the "." in
Sun puts the "." in
PostgreSQL puts the "E_fatalError - Database error" in
I have a test on this tomorrow, so I just wanted to make sure.
laugh.
HURD - Hurd's Under Research & Development
Unfortunately, I haven't found new data, but here is a list of January 2001. .com: 21,174,751 .net: 2,806,721 .uk: 2,078,474 .de: 1,732,994 .org: 1,614,740 .nl: 416,842 .kr: 325,203
...
The top ranks are:
1.
2.
3.
4.
5.
6.
7.
The numbers have certainly changed since then, but perhaps the ranks are still similar. Maybe someone has found new data?
...amusing when someone mispells...
Is this real irony or Alanis irony?
-- You see, there would be these conclusions that you could jump to
1) .com ORA-00936: missing expression .net mySQL:Cannot Connect to Local mysql server .de Filemaker Pro: 813, Record Synchronization error on network .org jdbc:postgresql:postgres
Exception caught 101, error: Network is unreachable .nl "errr, I think I have that number scribbled on that big wooden shoe..." .kr "ENLARGE YOUR PENIS!!!!"
2)
3)
4)
5)
6)
There aint no pancake so thin it doesn't have two sides.