Come on, admit it: you've always wanted to display the infomask bits from a tuple header in a human-readable manner, but you've never gotten around to it and you still keep htup.h in display while you peek around tuples.
Fortunately, that time is now past! Here's a short and simple recipe to decode the bits for your reading pleasure. Gone is the htup.h cheat sheet. Here's what you need:
We were able to fund two features for PostgreSQL, both of which will hopefully hit for 9.2. The first is work to be done by Greg Smith with pg_stat_statement. The other was fully funded by Heroku which is standardized URI support for libpq and psql. It is my hope that we will continue to use PostgreSQL Conference to actively fund features.
That said, there are changes in the wind. First, PostgreSQL Conference is changing from a semi-annual conference to an annual conference. There is just no way the community can support four north american conference (PgWest, PgEast, PgCon, Postgres Open). What is unknown at this point is whether or not PgWest and PgEast will continue, or if we will just merge them and have PostgreSQL Conference. What is known is that the next conference will not be on the East coast. We are currently negotiating with Denver, Seattle, and San Jose (for a repeat).
So what else is new? Generally speaking, the PostgreSQL conference is operated by a small team within CMD with a few select community members and partners picking up some stray pieces. That has changed this time around. We have an organization and planning committee of 26, all of whom are community members and attendees and/or speakers of the conference. These folks have been an invaluable input to the conference, allowing us to learn from the people that are actually giving us the money to pull this conference off.
Stay tuned for more information in the next couple of weeks on various decisions in regards to the conference!
These are filling up fast, so you will want to get your registration in.
Of note, Jim Mlodgenski maintainer of Stado (a proper, stable fork of GridSQL) will be teaching a Practical PostgreSQL Administration course. This is a full day course. Jim has graciously agreed to allow his percentage of the training revenue to be used for the feature development community initiative.
I received (reprinted with permission) this email from him today:
Hi Josh,
I am excited to say that the Schemaverse contest at DEFCON 19 went great! By the end of the tournament we had 108 registered players and over a million queries ran against the game in a four day span. Not only did the server do great as far as performance goes but the fact that it wasn't exploited during DEFCON is also an impressive stat to note.
I can also proudly tell you that your contribution was mentioned during my own two presentations, found in our How To guide, discussed at our contest booth (right by the front doors to the high traffic contest area! :D) AND was announced during the DEFCON 19 closing ceremonies during my allotted 2 minutes of speaking time.
The winner of your prize is Ian Haken (xxxx@xxxxxx.com). He kicked some butt in the competition and is certainly deserving of it. He has authorized me to send you his name and email. If you need any further details you can talk to him directly.
I likely sound like a broken record at this point but I really do need to say thanks again. Your contribution definitely helped us generate some interest in the first year of our competition and has helped us gain the respect needed to return with the contest for years to come.
Best Regards,
Josh (Abstrct) McDougall
http://schemaverse.com/
It was an honor to sponsor this contest. It is great little things like this that truly show the power of PostgreSQL in places you least expect.
Just a note, although the CFP is technically closed we have not closed the submission form, if you wanted to sneak in a talk or two you are welcome to.
As I have posted in previous articles (
Fixing foreign key deadlocks and
Part 2),
I am working on reducing the lock
strength required by foreign key checks. I have
a working patch
that solves a lot of the problems already; however it doesn't solve the one
problem that I initially set to fix. It turned out to require a bit more
rejiggering than I initially considered.
Note: this article assumes that you know what I have already done in the
patch I posted. If you want to follow through, I suggest you read
the first two links above as an introduction.
May 25th: Talk submission opens August 12th: Talk submission closes (EXTENDED!) August 16th: Speaker notification
Help us continue to provide the overwhelming support to the PostgreSQL Community we always have. Submit your talk today!
As a team I would like to think that CMD is really good at serving the community, serving its customers, and taking care of each other. However, when you reach out of your expertise and try something new it can fail and come back to bite you. CMD for the last two years tried that, we changed our model. We started listening to companies that have a different model than we did. We felt that we could learn from their success and possibly have some better fortunes of our own. What we learned was that although there was some good information to be had (and we have used that information), the model that was being dictated to us was not the model that would allow CMD to be more successful. We also learned that their model, wasn't nearly as successful as they lead people to believe.
One of the things that I love about the .Org business community is that we look out for each other. 2ndQuadrant, Consistent State, PgExperts, Credativ, OmniTI, and CMD (and a host of others, no offense guys). We actively seek ways to work with each other when we can, we lead exchange, we send people to other companies we know are good companies if we can't help a customer, we don't swipe customers (purposely, sometimes things happen) . There is a certain, comfortable quid pro quo. No matter the differences that Josh Berkus, Simon Riggs, Robert Treat, Kevin Kempter or and I may have on list, it is purely professional and at any point we will get together and have beer when we are at a conference or other event. We all have similar goals and they are, grow PostgreSQL, grow our companies and take care of our families (probably not in that order).
Although CMD never stopped working with these community partners, we did lose focus through trying to become a more dominant player. It is natural to see opportunity and be slightly blinded by it. To have someone hold out their hand and say, "We know a better way, wink, wink", and think, "Hey maybe they do, let's see where this goes.". In our case, we found the way wasn't better and the way was really smoke and mirrors. This could very well be our fault. Frankly, we were blinded by opportunity that never arose and like many others in this community I am as stubborn as a mule. I just refused to adjust pace before now.
I am strong in my convictions and I have beliefs in the way business should be done. CMD is going back to that. Those beliefs are founded on well over a decade of running this company in a manner that has assured that no team member has ever missed a paycheck including myself, that our debt has always been minimal if at all and that our communications with customers are upfront, honest and to the point. In case you hadn't noticed, we also don't employ sales teams.
So what does all this really mean? Well for one, CMD has introduced the Google Policy. This means that every technical person in the company can spend 20% of their time on community work and sometimes that will be more. In the case of Alvaro, we have successfully received sponsorship for the rest of the Foreign Key Locks patch and he is currently spending more than 20% time on community work for example. If all goes well, we will continue to be sponsored to write features, modules and other PostgreSQL based software. We have been sponsored to do quite a bit of it lately.
It also means that we will be attempting to reinvigorate our cross community relationships, although most of our relationships are solid I feel that not all of them have flourished the way they should. I would like to see those relationships stronger so we can continue to move .Org forward. With stronger relationships in the commercial satisfies the pre-requisite for future growth of the software community. Companies need to know they have someone to call, someone that will treat them right, someone they can trust to implement whatever it is they need with PostgreSQL. If those relationships are strong, any one of us can make sure we get those needs served, either by doing the work ourselves or handing it off to a more suitable candidate.
In short it means, more patches, more patch review, more sponsored work and hopefully more intermingling of like interests between PostgreSQL companies. That is one of the goals behind PostgreSQL Conference West raising funds for feature development. We want to continue to have PgWest (and PgEast) be a central place where community and commercial can get together and celebrate the common goals of PostgreSQL.