zillablog - postgres

Cloudy With A Chance Of Scale

nospam@example.com (Robert Treat) — Wed, 23 Nov 2011 15:57:00 -0500

Recently I met with a company looking for some long term advice on building out their database infrastructure. They had a pretty good mix of scaling vertically for overall architecture, while scaling horizontally by segmenting customers into their own schemas. The had a failover server in place, but as the business was growing, they were looking at ways to better future proof operations against growth, and also build more redundancy into the system, including multi-datacenter redundancy. After talking with them for a bit, I drew up a radical solution: "To The Cloud!"

I think I am generally considered a cloud skeptic. Most of how we are taught to scale systems and databases from a technical standpoint doesn't work well in the cloud. I mean, if you have a good methodology for problem solving you can make a lot of improvements in any environment; we've certainly seen that with customers we've worked with at OmniTI. But if you are just into looking at low-level numbers, or optimizing performance around disk i/o (generally the most common problem in databases), those methods just aren't going to be as effective in the cloud. That is not to say that if you are willing to embrace some of the properties of what makes for successful cloud operations, then I think it can be a pretty successful strategy. One of the key factors which I often see overlooked in most "will the cloud work for me" discussions is whether or not your business lends itself well to the way cloud operations work. In the case of this particular client, it's a really good match.

First, this company already segments their customer data, so there is a natural way to split up the database and operations. Second, they don't do any significant amount of cross customer data, which means they don't have to re-engineer those bits to make the switch. Further, the customers have different dataset sizes, different access patterns, and different operational needs, and most importantly, they pay different rates based on desired levels of service. This matches up extremely well with a service like postgres.heroku.com. Imagine that, instead of buying that next bigger server, instead of setting up cross-data-center WAL shipping, instead of buying machines in a different colo somewhere across the country, instead of all that, they could instead buy individual servers with Heroku, sized according to customer data size and performance needs. For smaller customers you start with minimal resources, and as the customer grows, you dial up the server instance size. Furthermore, you get automated failover setups, and an also easily store backups in a different datacenter based on given regions. You can even work to match customers to different availability zones based on their users endpoints. And if you want to do performance testing or development work, you can create copies of the production databases and hack away. These are the kinds of services OmniTI has built on top of Solaris, Zones, and ZFS, and believe me they will change the way you think about database operations.

Of course, it's not all ponies and rainbows. You still have to move clients on to the new infrastructure, but that should be pretty manageable. You'd also need to build out some infrastructure for monitoring, and you'll need to be able juggle operational changes. Some of this is not significantly different; pushing DDL changes across schemas is pretty similar to doing it across servers, but you'll probably want to create some toolsets around this. Also you're less likely to bear fruit from micro-optimizations; that doesn't mean that you throw away your pgfouine reports, but the return on performance improvements and query optimization will be much lower. That said, if you can get good enough performance for your largest customers (and remember, you'll have easy capabilities for distributing read loads), you end up an extremely scalable system, not just technically, but from a business standpoint as well. If you aren't building this on top of Heroku's Postgres service, the numbers will probably look different, but the idea that you've matched your infrastructure capabilities to a significant range of possible growth patterns should be compelling for both suits and the people who maintain the systems.

Checkpoints, Buffers, and Graphs

nospam@example.com (Robert Treat) — Wed, 16 Nov 2011 11:18:54 -0500

Last night at BWPUG, Greg Smith gave his talk on "Managing High Volume Writes with Postgres", which dives deep into the intersection of checkpoint behavior and shared buffers, and also into dealing with vacuum. One of the things I always like about Greg's talks are it's a good way to measure what we've learned between reading code and running large scale / highly loaded system in the wild. Even in the cases where we disagree, it's good to get a different point of view on things. If you manage Postgres systems and get the chance to see this talk, it's worth taking a look (and I suspect he'll post the slides up somewhere this week, if they aren't already available).

One of the other cool things that came out of the talk was one of the guys on my team again validating why we love working with Circonus. We have an unofficial slogan that with Circonus, "if you can write a query, you can make a graph". Well, Keith noticed that we didn't have any monitoring for the background writer info on one of our recently upgraded from 8.3->9.1 multi-TB Postgres, so he jump into Circonus and just like that, we had metrics and a graph faster than Greg could move off the slide. This will be awesome once we accumulate some more data, but here's a screenshot I took from last night while we were in the talk:

Yay graphs!

Update: Shortly after posting, Keith mentioned that he had updated the graph to speak in MB rather than Buffers. So, here is an updated screenshot with friendlier output and more data. (Note that Phil, one of our other DBA's, also flipped the buffers allocated to a right axis as well).

Understanding Postgres Durability Options

nospam@example.com (Robert Treat) — Tue, 08 Nov 2011 06:58:05 -0500

Most people tend to think of Postgres as a very conservative piece of software, one designed to "Not Lose Your Data". This reputation is probably warranted, but the other side of that coin is that Postgres also suffers when it comes to performance because it chooses to be safe with your data out of the box. While a lot of systems tend to side towards being "fast by default", and leaving durability needs as an exercise to the user, the Postgres community takes the opposite approach. I think I heard it put once as "We care more about your data than our benchmarks".

That said, Postgres does have several options that can be used for performance gains in the face of durability tradeoffs. While only you can know the right mix for your particular data needs, it's worth reviewing and understanding the options available.

"by default" - OK, this isn't a real setting, but you should understand that, by default, Postgres will work to ensure full ACID guarantees, and more specifically that any data that is part of a COMMIT is immediately synched to disk. This is of course the slowest option you can chose, but given it's also a popular code path the postgres devs have worked hard to optimize this scenario.

"synchronous commits" - By default synchronous_commit is turned on, meaning all commits are fsyncd to disk as they happen. The first trade-off of durability for performance should start here. Turning off synchronous commits introduces a window between when the client is notified of commit success, and when the data is truly pushed to disk. In affect, it let's the database cheat a little. The key to this parameter is that, while you might introduce data loss, you would never introduce data corruption. Since it tends to produce significantly faster operations for write based workloads, many people find that is a durability tradeoff they are willing to make. As an added bonus, if you think that most of your code could take advantage of this but you have some certain part of your system that you can't afford the tradeoff, this setting can be set per transaction, so you can ensure durability in the specific cases where you need it. That level of fined grained control is pretty awesome.

"delayed commits" - Similar sounding in theory to synchronous_commit, the settings for "commit_siblings" and "commit_delay" try to provide "grouped commits", meaning multiple transactions are committed with a single fsync() call. While this certainly has the possibility of increasing performance in a heavily loaded system, when the system is not loaded these will actually slow down commits, and that overall lack of granularity compared to synchronous_commit usually means you should favor turning off synchronous_commit and bypass these settings when trading off durability for performance.

"non-synching" - Fsync was the original parameter for durability vs performance tradeoffs, and it can still be useful in some environments today. When turned off, postgres throws out all logic of synchronizing write activity with command input. This does mean that running in this mode, in the event of hardware or server failure, you can end up with corrupt, not just missing, but corrupt data. In many cases this might not happen, or might happen in an area that does matter (say a corrupt index, that you can just REINDEX), but it could also happen within a system catalog, which can be disastrous. This leads many a Postgres DBA to tell you to never turn this off, but I'd say ignore that advice and evaluate things based on the tradeoffs of durability vs performance that are right for you. Consider this; if you have a standby set up (WAL based, Slony, Bucardo, etc...), and you are designing for a low MTTR, chances are in most cases hardware failure on the primary will lead to a near immediate switch to the standby anyway, so a corrupt database that you have already moved beyond will be irrelevant to your operations. This assumes that you can afford to lose some data, but if you are using asynchronous replication, you've already come to that conclusion. Of course, you are giving up single node durability, which might not be worth the tradeoffs in performance, especially since you can get most of the performance improvements with turning off synchronous_commits. In some situations you might fly in the face of conventional wisdom and turn off fsync in production, but leave it on in development; imagine an architecture where you've built redundancy on top of ec2 (so a server crash means a lost node), but you are developing on a desktop machine where you don't want to have to rebuild in the case of a power failure, and don't want to run multiple nodes.

Life is a series of tradeoffs between cost and efficiency, and Postgres tries to give you the flexibility you need to adjust to fit your particular situation. If you are setting up a new system, take a moment to think about the needs of your data. And before you replace Postgres with a new system, verify what durability guarantees that new system is giving you; it might be easier to set Postgres to something comparable. If you are trying to find the right balance on your own situation, please feel free to post your situation in the comments, and I'll be happy to try to address it.

PGDay Denver 2011 Wrap-Up

nospam@example.com (Robert Treat) — Mon, 24 Oct 2011 14:24:11 -0400

Last Friday was the first PGDay Denver, a regional one day Postgres conference, put on by Kevin Kempter and the folks who run the Denver Postgres User Group. We had between 50 and 75 people, which is pretty good turnout for a first time event. I gave two talks, my "Essential PostgreSQL.conf" talk (slides here) and my "Advanced WAL File Management with OmniPITR" talk (slides here). It was my first time in Denver (outside of the airport at least), and I have to say that the city is very well laid out for conference goers. The one tricky part was getting from the airport to downtown, but once you are downtown, their are plenty of good places to eat/drink, plenty of hotels, and the conference center itself is massive. After a couple nights on the town, I was honestly left surprised that I hadn't been to a conference here before (maybe OSCon should swing through some year?) and hoping I'll get the chance to go back. In any case, thanks to the PGDay Denver folks for putting together a nice event, and hopefully we'll see others follow their lead with more PGDay's in their part of the country.

On Clouds And Data

nospam@example.com (Robert Treat) — Fri, 26 Aug 2011 02:03:00 -0400

I'm sitting in SFO tonight, awaiting my return trip back to Hurricane Pending Maryland. (As a former Floridian, I must of course scoff at any notions that this hurricane is significant). Walking through the airport I noticed a large billboard about "Big Data and the Cloud". This is the kind of billboard you only see in Silicon Valley; I don't see signs like that in Portland or Ottawa, and certainly not when I had to change flights in Detroit this year.

Anyway, these two buzz words aren't a local phenomenon, and are actually taking the tech world by storm. Big Data has become serious enough that there are multiple conferences now for folks interested in the topic. And cloud, well, perhaps harder to define, but more and more businesses are moving to the cloud every day. The problem here is that, most of the traditional ideas on big data run entirely counter to the ideas that work well in the cloud.

Last spring I moderated a panel PGEast in New York that focused on Postgres in the cloud. As someone who works on multi-terabyte systems, and someone who deals with cloud servers on at least a semi-regular basis, I tried to prod and poke my panelists into sharing their take on how they see Postgres's role in the cloud. Not too surprisingly, the idea behind "Big Data" on Postgres in the cloud was not a particularly popular one. The tools you need to do the job effectively with Postgres just aren't there. Not to say you can't try, but so far I haven't seen many wild successes.

Next month at Surge though, I'm going to be involved in another panel focusing on "Pushing Big Data To The Cloud". This time though I'm turning over moderating duties to long-time thought leader in the MySQL community Baron Schwartz. Joining me on the panel are several folks who all have a stake in the idea of Big Data in the cloud; John Hugg and Philip Wickline from VoltDB and Hadapt, respectivly, two new database vendors built with scale-out in mind; Bryan Cantrill, VP of Engineering at Joyant, a cloud provider with thier own strong opinions on dealing with data in the clouds, and Kate Matsudaira, someone who is currently managing those multi-TB databases, all in the cloud, over at SEOMoz. This should be a really good mix of people using different technology, with different biases against the problems involved. If you're looking to work on Big Data in The Cloud, I hope you'll join us, it should be a lot of fun.

Paying Attention Pays Off

nospam@example.com (Robert Treat) — Mon, 15 Aug 2011 10:57:00 -0400

I often run my ops like I take care of data; a bit overzealously. Case in point, when setting up a new database, I like to throw on a metric for database size, which gets turned into both a graph for trending, but also an alert on database size. Everyone is always on board with trending database size in a graph, but the alert is one people tend to question. This is not entirely without justification.

On a new database, with no data or activity, deciding when to alert is pretty fuzzy. When we set up a new client within our managed hosting service, I usually just toss up an arbitrary number, like 2GB or something. The idea isn't that a 2GB database is a problem, it's that when we cross 2GB, we should probably take a look at the trending graph and do a projection. Depending on how things look, we'll bump up the threshold on the alert to a new level, based on when we think we might want to look at things again. For example, in this graph we take a month long sample, and then project it out for three months. We can then set a new threshold somewhere along that line.

While this is good for capacity planning, there's more that can be gained from this process. The act of alerting forces us to pay attention. And if we get notices before our expectations, we go back in and re-evaluate the data patterns. Of course, some times people will question this. Getting a notice that your database has passed 4GB can seem pointless when you have 100+ GB of free space on your disks. And besides, isn't that what free space monitors are for?

Here is a graph of another of our clients database growth. Their data size is not particularly large (don't confuse scalability with size; it doesn't take a large database to have scalability issues), but what's important is that we kept getting notices that the size was growing, and when talking with the developers, no one thought it should be growing at nearly this rate. Eventually we were able to track down the problem to purging job that had gone awry. Once that was fixed, the growth pattern leveled off completely (and the database size returned to the tiny amount that was expected!)

A funny thing happened on the way to September

nospam@example.com (Robert Treat) — Wed, 17 Aug 2011 11:13:00 -0400

In spite of all previous notions to the contrary, thanks to some last minute wrangling by the conference organizers, I will be making the trek out to Chicago this September for Postgres Open after all. I had been planning to sit out the event and just stay focused on Surge (which, I must say, looks even more kick ass than last year), but after looking at the schedule, and some persuading at OSCon, I'm very excited about what has been put together, and look forward to seeing many of my fellow Postgres community members once again.

Oh, and in case you were wondering, I'll be reprising my talk from this years Velocity conference, "Managing Databases in a DevOps Environment". At Velocity, the talk was intended to highlight how people already familiar with DevOps should approach their databases systems. I'm not sure how well "DevOps" is understood within the Postgres community, so I think I'll try to emphasize the differences between managing databases and traditional services, to hopefully give better expectations to DBA's whose organizations might be undergoing such a change. If you're going to be at Postgres Open and are interested in the topic, I'd love to hear your feedback on what aspects of this topic you're most interested in. (PS. I'll also be heading to the Velocity Summit next week in San Francisco, for those attending, I'd love to hear your thoughts on this topic as well).

Maybe they just like it better?

nospam@example.com (Robert Treat) — Mon, 08 Aug 2011 08:37:00 -0400

There has been a lot of chatter the past week about Apple replacing MySQL with Postgres in the new OSX Lion Server [U.S. | England | New Zealand ]. Most of it seems to tie things back to Oracle's new stewardship over the MySQL project, a lot of that stemming from what I would say is FUD from the EnterpriseDB folks, regarding doom and gloom about the way Oracle might handle the project in the future. Not that the FUD is entirely unwarrented; While Oracle has done a pretty decent job with MySQL so far, looking at what Oracle has done to projects like Open Solaris certainly would make one queasy. And yes, we've seen an uptick in people asking for help with Oracle/MySQL to Postgres migrations since the acquisition of Sun. That said, I have an alternative theory. Maybe they just like it better?

Continue reading "Maybe they just like it better?"

Actually, I am not going to PGWest (and you might not want to either)

nospam@example.com (Robert Treat) — Tue, 05 Jul 2011 23:02:50 -0400

OK, I am just trying to set the record straight. People are still confused thinking I might be going to PGWest, but I'm not. I know where the confusion comes from; on the PG West website, there is a picture of me in the banner graphic; which makes people think I am going to PG West. This is not unreasonable, it's just untrue. For what it's worth, I did ask Joshua to remove my picture when people first started asking me if I was going, and he said he would, but that was well over a month ago. I do think he will take it down, but in the mean time, I figure I should at least put some effort into clarifying things myself. So, to be clear, I will not be going to PG West this year. Also, to be clear, it's not that I have anything against PG West per se. I've gone to multiple PG West cons in the past, and I suspect I'll probably go to more in the future. It's just that this year, I've got something better to go to. That something is Surge.

What is Surge?

Surge is the premeire conference on internet scalability. Now, I have to disclose, I am affiliated with the conference, but this conference really stands on it's own merits, no question. Now in it's second year, Surge packs an incredible lineup of people leading large scale operations on the net. Reading through the speakers list, I see companies like Yahoo, Wikia, Message Systems, Varnish, MyYearbook, Percona, Etsy. If you are trying to grow at scale, you can learn a lot from this crowd.

Yeah, but I'm a DBA

So most people going to PGWest are probably DBA's, or at least work closely with Postgres, so it makes sense for them to go to PGWest; I get that. But here is why you may not want to. The thing about Surge is that, while it isn't a database conference per se, a fair amount of the content does revolve around managing data. Let's face it, if you are running a website at scale, chances are you have to deal with large amounts of data. Whether it's massive data on disk, or dealing with massive throughput of data, or trying to figure out how to visulaize all that data, Surge has it covered. And what I find most intriguing is that because Surge is not focused on any particular technology, you get to see both problems and solutions from different angles, which I think helps to learn even more. Of course, you don't have to take my word for it; scan the speakers list, check out the talk profiles, and see if there isn't something there looks awesome.

See you in September

In any case, record set straight. You know where I'll be, I hope to see you then. Oh, and in case you need incentive, early bird pricing is still in effect until the end of July. Get on it!

PGEast Slides Available On Slideshare

nospam@example.com (Robert Treat) — Sun, 03 Apr 2011 00:32:00 -0400

I think I'm just about dug out from last weeks NYC trip for PGEast. I have to say I had a good time at the conference, although I was kept busy enough not to be able to get to see nearly as many presentations as I would have liked. One thing I did walk away with was a renewed appreciation for the projects we get to work on at OmniTI. I angled most of my talks toward PostgreSQL 9.0, going in thinking that a majority of people would have probably made the move already. Apparently that isn't the case, which in retrospect seems obvious; a majority of our customers still run some 8.x version of Postgres, as we work to vet applications and find the right windows to make their upgrades happen. Still, we are fortunate to have some clients who are very aggressive when it comes to server versioning, and we're lucky enough to get to run a healthy amount of Postgres 9, in some cases with fairly complex distributed server arrangements.

In any case, as per the title of this post, slides for my talks are now up on slide share, feel free to peruse, and if you have any questions please let me know.

Upserting via Writeable CTE

nospam@example.com (Robert Treat) — Wed, 16 Mar 2011 11:40:28 -0400

Earlier today my colleague Depesz posted a nice write up showing one of the use cases for the new 9.1 feature, "Writable CTE's". It certainly shows one handy thing that this feature will enable, but it's not the only one. Here's a quick little bit of SQL I have been playing with for some time that re-implements the infamous "UPSERT" command (a long time sticking point for people trying to make MySQL apps more cross-database compatible) into Postgres.

pagila=# select * from actor where first_name = 'AMBER' and last_name = 'LEE';

 actor_id | first_name | last_name | last_update 

----------+------------+-----------+-------------

(0 rows)



pagila=# with upsert as 

pagila-# (update actor set last_update = now() where first_name = 'AMBER' and last_name = 'LEE' returning actor_id) 

pagila-# insert into actor (first_name, last_name, last_update) 

pagila-# select 'AMBER', 'LEE', now() WHERE NOT EXISTS (SELECT 1 FROM upsert) ; 

INSERT 0 1



pagila=# select * from actor where first_name = 'AMBER' and last_name = 'LEE'; 

 actor_id | first_name | last_name |        last_update         

----------+------------+-----------+----------------------------

     201 | AMBER      | LEE       | 2011-03-16 11:29:15.611445

(1 row)



pagila=# with upsert as 

pagila-#(update actor set last_update = now() where first_name = 'AMBER' and last_name = 'LEE' returning actor_id) 

pagila-# insert into actor (first_name, last_name, last_update) 

pagila-# select 'AMBER', 'LEE', now() WHERE NOT EXISTS (SELECT 1 FROM upsert) ; 

INSERT 0 0



pagila=# select * from actor where first_name = 'AMBER' and last_name = 'LEE'; 

 actor_id | first_name | last_name |        last_update         

----------+------------+-----------+----------------------------

     201 | AMBER      | LEE       | 2011-03-16 11:30:21.244226

(1 row)

Now, to be fair, this bit of SQL does have a race condition (think two people trying to insert the same actor at the same time), so it doesn't really solve all of your problems, but if you are looking for a quick hack, it might just do the trick. Also don't be afraid to play with it; this was like 2 minutes of thought and making sure the syntax worked; you could certainly try turning it around or coming up with other variants. That's actually one of the coolest things about this feature; waiting to see what use cases people come up with for it.

Monitoring Read vs. Write Activity In Postgres

nospam@example.com (Robert Treat) — Tue, 01 Mar 2011 00:28:00 -0500

If you spend anytime either giving or receiving database tuning advice, perhaps the most common phrase you will hear is "it depends". Of course that is made in reference to a whole lot of things, but one of the things it depends on is read vs write load. While that's easy to point out, it's not always that obvious as to how best to measure read/write load for a system.

Continue reading "Monitoring Read vs. Write Activity In Postgres "

Why the F&#% Doesn't Postgres Have Hints?!?!

nospam@example.com (Robert Treat) — Mon, 07 Feb 2011 08:33:00 -0500

Once again someone has brought up the idea of having a hints system in Postgres, which means once again we're all subjected to watching people trod out the same tired, faulty, and even self-contradictory reasons to try to justify the idea that Postgres doesn't have, need, or even want a hinting system. As frail as the arguments might be, people are so entrenched in their positions now that even having a discussion on the topic is difficult. And in fact, there are really two discussion going on here; one is whether Postgres should have any type of hinting system, and the other a more specific discussion on if we should have a query hinting system.
Continue reading "Why the F&#% Doesn't Postgres Have Hints?!?! "

A present from my filesystem

nospam@example.com (Robert Treat) — Tue, 18 Jan 2011 22:12:38 -0500

People ask me why I haven't blogged much lately and I generally tell them I've been busy fixing broken stuff. Then they tell me to blog about the broken stuff I'm fixing. So, ok. Here's a random encounter from before the holidays....

There's nothing like trying to log into a database server to do some simple schema work, only to have you're login hang trying to load your session. After some brief poking around and attempts to login with different accounts, I was able to see that we had a disk problem on the database. (Nail in the coffin, zpool status, the zfs command which shows the condition of your drives, was hanging trying to show the last pool). So, poke the SA's and see what they can dig up... and unfortunately things were bad enough, we were going to need a reboot. So, we reboot.

Upon restart, well, things don't restart; where "things" means postgres. SMF shows that we tried to start, but something has gone awry. Looking in the database logs, I see this

2010-12-23 17:29:16 EST:resmon@127.0.0.1(32789):782: FATAL: the database system is starting up
2010-12-23 17:29:17 EST:sauron@10.0.0.231(58978):783: FATAL: the database system is starting up
2010-12-23 17:29:18 EST:@:494: FATAL: could not create relation 16385/58326/58757497: File exists
2010-12-23 17:29:18 EST:@:494: CONTEXT: xlog redo file create: 16385/58326/58757497
2010-12-23 17:29:18 EST:@:492: LOG: startup process (PID 494) exited with exit code 1
2010-12-23 17:29:18 EST:@:492: LOG: aborting startup due to startup process failure

Continue reading "A present from my filesystem"

Scalability, I has it

nospam@example.com (Robert Treat) — Tue, 26 Oct 2010 17:35:53 -0400

On Monday I spoke at the Highload++ conference in Moscow, Russia. This is an annual conference put on by several local Russian tech folk that focuses on large scale website architectures. This conference covers the full stack, which includes database, which includes Postgres, which is where I get included in all of this. I gave a talk with a rather generic title, "Scaling with Postgres", which incorporates both some thoughts on "tech culture" within organizations trying to scale Postgres (gleaned from years of working with these types of clients at OmniTI, plus quite a bit of mind-melding and discussion a few weeks ago at Surge conference), mixed in with some hands on pointers for those trying to do it with Postgres. I've put slides up on slideshare for those that want to view it, and I believe the Highload folks will have video up at some point.

Along side my talk were talks from fellow Postgres contributors Simon Riggs and Bruce Momjian, which focused on performance, upgrading, and replication. I thought all of the talks were good, although given some overlap in Simon and Bruce's talks, I think it would have been cool to cut the talks time and maybe have a short panel for open Postgres Q&A for all three of us. (This is likely difficult from a practical perspective, given the need for translations, but it seems doable). Instead, since Simon went first, he ended up taking the brunt of people's questions; which was amusing for Bruce and me, but I think a panel would have been good. Maybe next time.

Anyway, I want to thank the folks running Highload for inviting me to speak, and working through the travel shenanigans. I found the conference very nicely run, and the growth they are getting in attendance is a good sign for the Russian tech community!

PS, someone at the conference had asked me about getting reconnoiter support; since I couldn't get a card, I'll just toss a link out here for him, or anyone else interested: http://labs.omniti.com/labs/reconnoiter/wiki/Support

Postgres returning for Google Summer of Code 2010

nospam@example.com (Robert Treat) — Fri, 19 Mar 2010 12:06:00 -0400

I'm very happy to announce that the Postgres project has been selected to participate in this years Google Summer of Code program. Over the next couple weeks we'll be looking to solidify our mentor base; if you work on Postgres and would be willing to mentor a student, please send me a note so we can get you signed up. If you are a student and you're interested in working on Postgres, now is the time to get your proposal together. Student applications will open up on March 29th, so we'd like to have our mentors in place for review, and hopefully had students discussing with the Postgres devs their proposals as much as needed. If anyone has any questions, feel free to email me, or track me down on irc.

Handy links for Postgres GSoC:

Our ideas page for GSoC

Our loose attempt at organization

Our Postgres page on the GSoC site

Users Guide to GSoC

Thanks everyone, I'm looking forward to another interesting year with GSoC, and hoping you'll join in.

Article translated to Belorussian

BWPUG September Meeting 2010-09-08: PostgreSQL Security and SE-Postgres

nospam@example.com (Robert Treat) — Tue, 07 Sep 2010 12:40:41 -0400

A reminder that tommorrow night, BWPUG will be gathering for its September meeting. This months we're rounding up the gang to discuss "PostgreSQL Security via SE-Postgres", including the current TODO's, and what to focus on now that 9.0 is just around the corner and 9.1 development will be starting in earnest. We expect to have a good crowd on hand, including some potential out-of-towners, so we hope to see you there.

When: Septmber 8th, ~6:30PM.
Where: 7070 Samuel Morse Dr, Columbia, MD, 21042.
Host: OmniTI

As always we have time for networking and likely hit one of the local
restaurants after the meeting, hope to see you there.

Now What? (wrt OpenSolaris and your database)

nospam@example.com (Robert Treat) — Mon, 16 Aug 2010 09:45:11 -0400

Last week's "announcement" of the death of OpenSolaris has steered a lot of questions my way about where people should go, and/or where OmniTI will go, now that OpenSolaris future looks non-existent. As one of the more open users of Solaris related technology, and running some beefy loads on top of it, it makes sense that people would be curious as to what we might be doing next. I would start with saying that as a company, we don't have an official policy on this yet, and probably won't. We evaluate each situation on a customer by customer basis, so what follows here is more my personal feelings on what people should do at this current point in time.

The one thing I have noticed from the people I have already spoken with is that there seem to be two major camps, an over simplification to be sure, but I break this down into the free software camp (those motivated by a desire to remain on open source, and/or support, free software as a primary driver of technology decisions), and those more interested in the technology than the ideals behind it. Depending on where you fall into that spectrum, you have different options available to you, and will likely reach very different conclusions.

Too Soon?

The first thing I have said to everyone is that it is honestly too soon to make any moves. Oracle is notorious for being poor communicators, and at this point I don't think we've seen enough official communication to really know what's going to happen. This doesn't mean you can't start planning though! We've been looking at some of the available options since before the Oracle/Sun merger was closed, so it doesn't hurt to start evaluating the options out there. However there's no need to rush in to things; it is possible that the announcement of OpenSolaris's death might be premature. I personally don't believe Solaris can't survive based on the model we've just seen laid out; there are too many people learning the gnu tool chain who won't be willing to invest big money into a tool that is hard for them to use. They need a low cost / free option for people to familiarize themselves on (and all the better if it installs gnu tools by default). There's an outside chance Oracle might come to this conclusion, which would give new life to OpenSolaris.

A more likely alternative to that theory is that some other group might pick up OpenSolaris maintenance and start pushing it forward. Certainly not an easy task, but there are already several different distribution of OpenSolaris available, so the userland level management has the resources, we mostly would need to figure out how to handle the more core technologies that have been maintained by Sun. I think this might also be possible, as there are numerous companies already heavily invested in OpenSolaris technology, and there are Solaris internals hackers looking to move out of Oracle, it's not an impossible leap to think we might see something worked out. And if Oracle continues to make technology available via the CDDL (which most of the current signs seem to indicate), this could work out. I would say that this might not resemble the OpenSolaris as it is now, but could definitely be an option for current users who'd like to remain on the OpenSolaris platform.

Other Options?

Of course, you might not want to put all your eggs in that basket. So what other options do we have? Well, that mostly depends on what you're getting out of OpenSolaris now, and what you want out of your OS going forward. For many people, I suspect that Solaris 11 Express might be a suitable replacement, especially for those running mixed OpenSolaris / Solaris environments. Migrating up to full Solaris 11 will also cover most of your technology needs, so depending on pricing I suspect people may find that a cheaper alternative to migrating to a new platform. Of course, if you want to stick with a free software solution, this won't really be an option.

FreeBSD seems to be the most obvious alternative platform. If you're currently taking advantage of dtrace, zfs, and zones, FreeBSD gives you options to cover all three. It won't be the same; the dtrace and zfs implementations are pretty close aiui, but for zones you'll probably have to use either Jails or OpenVS, neither of which am I a fan of. I think you'd also find a larger overlap in system utilities (tar, find, grep, etc..) between FreeBSD and Solaris, so for people (and scripts) making the transition, this might be an easier move. The big question here is probably hardware support; if you can't get FreeBSD running on your hardware, that's likely to be a show stopper, unless you can work out a new hardware purchase in the transition

So, if you don't want to go closed Solaris, and FreeBSD isn't an option, that probably leaves you on Linux. People sometimes think I don't like Linux; I'm actually very comfortable on it. My first "unix" was Linux, and we run some extremely demanding systems on Linux and it has performed well in those cases. However if you're trying to do deep introspection, systemtap is a poor man's dtrace. And if you are relying on zfs, you'll have a hard time finding a suitable replacement amongst the current Linux options. Personally I am most comfortable on ext3, but I tend to give up on file system snapshots, which is a painful submission if you have to make it. XFS is probably the next most common option, and generally I've no bones about using it if you want to avoid ext3. Of the three "advanced" replacements; ext4, btrfs, and zfs on linux; I think ext4 is probably your best bet, but only because zfs is too new for any serious database systems, and if you are moving off OpenSolaris to get away from Oracle, "butter" seems like an odd choice.

And so...

I think it's wise to keep things in perspective. There are some cases where you want to be a technology leader (we've been running Postgres 9 for months on some systems), but generally speaking when it comes to picking the operating system and filesystem for your database, it's best to tread lightly. Now is a fine time to start evaluating your options; at least figure out what features are critical to your enterprise that you'll need to replace (and don't just think about database, you might be relying on crossbow for something, or who knows what else). We'll certainly be watching the current options available, and I suspect diversifying a little, over the next 6 months, as we wait for the picture to clear up where we can. We're not in a hurry (after all, we do have the source code of what we're running now), and I don't see much reason for others to be either.