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:
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.
A recurring question in our community is, "How do I get feature X sponsored?". It is a frustrating question because there are many variables that are at play anytime you do development within an Open Source project. Just because you can develop the feature doesn't mean that the community actually wants the feature. There is also the problem of raising money for a feature, a lot of very skilled hackers do not have the contacts or frankly person skills to "sell" their idea. Once you have the money even more problems arise, what if you underbid the project? What if you can't get everyone to pay that said they would? What if you miss a commit deadline and you have to wait for the next release to start development? The list goes on and on.
The traditional method of getting a feature developed would be to contact a company to do so. There are many people and companies that are used to working in the community, who know how to navigate the shark infested waters and are actively willing to work with you to get whatever feature done. Two of the most well known companies that do this are Command Prompt (duh moment), and 2ndQuadrant. We both have had much of the feature development we do for PostgreSQL sponsored by our customers (some of them, mutual customers). If you have a feature that you wish to get developed I highly recommend contacting one of us.
The traditional method can be too much for a single entity to bare. If you have a feature that is 15,000 USD to develop, that just might be out of the budget of the sponsoring company and it is certainly out of the budget of most individuals. In some communities there is a bounty system where multiple entities can chose to donate to get a bug squashed or a feature developed. Unfortunately, bounties can go on forever and very little money is normally raised. So what do you do?
The PostgreSQL Conference organizers team had an idea. What if, we take one of the resources we are rich in and use that resource in a manner that allows the community as a whole to benefit. What is this resource you might ask? Well people of course. Every 6 months the PostgreSQL Conference pulls more people into a single room than any other PostgreSQL event. What if the PostgreSQL Conference worked out a way to get those people to part with their hard earned dollars to get a feature developed? Imagine, one night instead of pub crawling if we put that 50.00, 100.00 or 250.00 to work for the betterment of PostgreSQL?
If every person that attended #PgEast gave 100.00 to feature development, we would have raised $23,000 dollars. That would have more than paid for the ALTER TABLE ALTER COLUMN work that Command Prompt would like to develop. So that is what we are going to do at #PgWest. This year at #PgWest there will be up to 5 proposals on the table to sponsor. Only one will be from Command Prompt, we would like the others to be from other developers and companies are welcome to submit as well. Further, #PgWest will also be donating a portion of the registration fees to get these features developed.
Stay tuned for how to submit your proposals.
PostgreSQL Conference West Call for Papers