credativ U.S. provides Open Source support and consulting services focused on the WebOps space. At this time we are primarily looking for DBA/DBRE folks, although we do have some other positions in the SRE/Sysadmin space available as well. We are 100% distributed company. We encourage you to check out our available listings at https://careers.smartrecruiters.com/CredativLLC
It is worth noting that while extremely rare, it is possible that we could encounter an issue during packaging which might necessitate a change, in which case that commit stamp might not be the same. Unless folks are comfortable working directly from git, it is probably best to wait for the official release.
There was an additional talk on this subject from Bryan Cantrill at Surge 2015 which should be available in video form soon. Interested parties might want to follow @OmniTI on twitter to catch the announcement.
"Both are equally valid", except that the former (a data type) is more equally valid than the latter (pseudo-version), since the SQL Standard defines it that way.
According to the current ruby driver author, the latest driver should support back to Postgres 7.4. Any older version of postgres is unsupported by the postgres project itself, but if you really need something that old, you should be able to use the old "postgres" gem. Granted there might be driver / database / platform combinations that have issues, but if you know of one, please submit a bug report with the specifics. HTH :-)
Yikes... didn't mean to make you so defensive! Let me retort and clarify (hopefully with understanding that this is not meant as criticism) :-)
First, I know people doing rails+slony; I think the most common way is by piping the sql to a file and then to slonik, but there are other methods too. Granted, it's not awesome. For a new rails/postgres shop, I'd look at pgpool (provided you really needed replication, which is dubious for a lot of people)
Second, this wasn't really about postgres/mysql. If you had told me you went from MySQL->Oracle 2 days before launch, I'd have concerns. Heck, even going from Postgres 8.2 -> 8.3, I'd want to make sure you had good test plans (which it sounds like you did).
As a general rule, swapping out your database infrastructure is not something I recommend people take lightly. Yes, rails shops have already decided that the application code is more important than the data, so it's a lot easier to do, but given subtle differences in SQL implementations, people still get bitten by it.
Please note, I never said you did anything wrong. You did something risky. Most people don't succeed with risky (which is why it doesn't sound like a good idea to me), but since you did I have to give you credit (again) for making a ballsy call and pulling it off. But I think even you realize that you probably would do things different if you had to do it over again.
Wow! For less than $5000 and a days work, you could have hired any number of postgres consultants to setup PITR warm standby for you (or Slony if you really thought you needed the read slaves). Instead, you migrated your entire architecture over to another database system. Doesn't sound like a good idea to me, but I have to give you points for chutzpah!
Just to clarify, hot standby wasn't backed out, because the changes were never "in". There was a working patch set against the 8.4 tree (which you could still get today) for hot standby, and the testing/review of that code ran into enough corner cases that the reviewers thought it was best to push it. While many of the same people are involved in the synchronous replication piece, the issues in that code didn't really play a part (it had pretty much been decided at least month ago that synchronous replication wouldn't make it)
Anyone who thinks you can scale writes by adding more masters is plain ignorant on the subject. The only way to scale writes is with better hardware or federation of application/data. The first of those is easy, the latter is hard.
Yes, but the other way around (Oracle's implementation of SQL lines up closer to Postgres). Also, Postgres has a procedural language based off Oracle's PL/SQL language called plpgsql, so if you have experience in one, learning the other is pretty simple.
credativ U.S. provides Open Source support and consulting services focused on the WebOps space. At this time we are primarily looking for DBA/DBRE folks, although we do have some other positions in the SRE/Sysadmin space available as well. We are 100% distributed company. We encourage you to check out our available listings at https://careers.smartrecruiters.com/CredativLLC