Nordic PGDay 2014 - wrap-up of the wrap-up
Nordic PGDay 2014 was just over a week ago in Stockholm, Sweden, and was definitely a success. A lot more people than we initially expected had the event sell out completely a couple of weeks before it happened. A week later we've now collected the feedback forms that people filled out (a big thanks to the 25-30 people who did fill them out - a 30% "hit rate" on feedback forms gives us a pretty good input).
I'll lead with a few graphs that fairly well represents the feedback:
In particular, that every person who filled out our feedback would recommend the event to friends or colleagues is definitely a flattering grade!
Nordic PGDay 2014 - come join us up north!
It's been discussed for several years, so I'm very happy to finally be able to announce that next year, there will be a Nordic PGDay, in Stockholm, Sweden, on March 20th. It will follow a pattern that is common to those of you that have already visited other PostgreSQL event - a combination of great talks from PostgreSQL insiders, and a hallway track to meet and talk with other PostgreSQL people. As this is our first instance in the Nordics, it will be a single-track single-day event, but we hope to grow it in the future.
Our main target audience is in the Nordics, and we hope to see a lot of visitors not just from Sweden but also from our neighboring countries. Since this means the official language of the conference will be English, we will of course also welcome both visitors and speakers from the rest of Europe and the world as well!
We have not yet opened our call for papers, but plan to do so shortly. We have also not opened registration yet, as we do not know exactly what the entrance cost will be yet. This will be depending on how many sponsors we can sign up for the event - which we have also not opened up for yet (a pattern is emerging here). But the date and venue is set, so mark your calendars and start moving other events around so you can be sure to make it...
If your company is interested in sponsoring the event, please let us know at sponsors@nordicpgday.org, and we'll be sure to send you our sponsorship information as soon as it's available!
For the rest of you, keep up with our website or follow us on Twitter for updates!
See you in Stockholm in March next year!
PGConf.EU 2013 feedback results
It seems I blog a lot more about conferences than about technology these days, and that sometimes makes me a bit sad. Not because I blog too much about the conferences, but that I don't blog enough about tech stuff.. But regardless of that, it's time to post our feedback from this years conference.
As we've collected the same statistics as previous years, it's easy to compare with previous years. And it turns out that a fair amount of the statistics are very similar.
It appears we are doing a decent job of keeping up satisfaction, with almost exactly the same score as last year for overall impression and program.
There is a small drop in the top score, but it's well within the margin of error of the sample. But of course, it just means that we have to keep working hard to keep the score high for next year as well, which we're very happy to see!
PostgreSQL conference registration updates
Right now we're hard at work settling the last details for PostgreSQL Conference Europe 2013 in Dublin, Ireland. But for those of you who wish to attend, you have an even closer deadline to consider - to qualify for the discounted Early Bird rate, you must complete your registration before September 16th, only a few days away! This is your best chance to learn about a large umber of PostgresSQL topics, from case studies to deep technical sessions about backend engineering. So take you chance and go register now!
In other conference related news, next week is Postgres Open in Chicago. I'll be there along with many other PostgreSQL contributors, to deliver a set of presentations almost as good as the one in Dublin. There are still some tickets left - why not go to both conferences!
New committers to PostgreSQL
During the closing session of PGCon this year, the core team announced the addition of four new committers to PostgreSQL:
- Jeff Davis
- Stephen Frost
- Fujii Masao
- Noah Misch
These have all been involved in both writing new code for PostgreSQL and reviewing other peoples patches during the latest couple of development cycles. With this addition, we will increase the capacity to handle the rising number of contributions we get, and get even more features into the upcoming versions of PostgreSQL.
Welcome to the team!
PostgreSQL Conference Europe 2013 - dates and location
Finally we're ready with phase 1 of the planning of PostgreSQL Conference Europe 2013.
PGConf.EU 2013 will be held on Oct 29-Nov 1, in at the Conrad Hotel in downtown Dublin, Ireland.
The format will be the same as previous years - one day of training before the main event consisting of three days fully packed with sessions about PostgreSQL.
We are hard at work to get our sponsorship campaign ready and intend to launch it within April. Also we are working on the call for papers and opening the registrations. So, please stay tuned and think about possible talk submissions!
So for now - mark your calendars, and start planning your trip! Follow the RSS feed from the website or our twitter feed for updates as soon as we know more details!
We look forward to seeing you this autumn on the Emerald Isle.
About security updates and repository "lockdown"
I have received a lot of questions since the announcement that we are temporarily shutting down the anonymous git mirror and commit messages. And we're also seeing quite a lot of media coverage.
Let me start by clarifying exactly what we're doing:
- We are shutting down the mirror from our upstream git to our anonymous mirror
- This also, indirectly, shuts down the mirror to github
- We're temporarily placing a hold on all commit messages
There has been some speculation in that we are going to shut down all list traffic for a few days - that is completely wrong. All other channels in the project will operate just as usual. This of course also includes all developers working on separate git repositories (such as a personal fork on github).
We are also not shutting down the repositories themselves. They will remain open, with the same content as today (including patches applied between now and Monday), they will just be frozen in time for a few days.
Why?
So why are we doing this? It's pretty simple - it takes a few days to prepare packages for all our supported platforms, to do testing on these, and get them ready for release. If we just committed the security fixes and then proceeded with the packaging, that would mean that anybody who was following our repository would be able to see those fixes a few days before the fixes were available to the majority of the users. That also means that anybody looking for the flaw would get a few days of time when the full details of the bug was in the open (since the fix was applied in public), but yet all the installations around the world would be unpatched and left wide open for exploit.
By restricting access to view the patches until release time, we close this window. Yes, the vulnerability is still in the code that is out there today. But it has been in there for a few years, and nobody (that we know of) found it in that time. Hopefully, nobody will between now and release time. But by not explicitly showing the bug, we're at least keeping that risk as low as possible while still being able to warn our users that they will need to apply the patch as soon as it's out.
We do realize that this will make some people look harder at the PostgreSQL code over the next couple of days trying to find this bug, and write an exploit for it.
But you're using git?
I've seen a couple of comments along the line of "isn't this where you should be using a DVCS like git you're using, letting the people building the security fixes do that in a separate repository and merge it once ready, not needing to shut down the central one".
Turns out that is actually exactly what we are doing. The security fixes are mostly already developed, and as such are sitting somewhere else from the main repository. But we need at some point to merge these into the main repository, in order to let people build the packages. We only close down the repository mirroring right before this merge is done, and until the packages are ready to be released. It's not the work to develop the patch that requires the shutdown of the mirroring, it's the work to build and release packages.
The other advantage of the fact that we are using a DVCS, is that development does not stop during this time. Anybody working on a patch can keep working on it in their local copy of the repository. It's only the merge ("apply") of the patch to the upstream master branch that's going to be delayed. And that affects a much smaller group of people. Of course, it is a bit of an extra annoyance since we are currently trying to close out the open patches for the next release, but it's not a huge difference for most developers.
Are you going to publish the fixes eventually?
Yes, absolutely! We are not going to permanently hide any information, or try to obfuscate the contents of security patches (coughunlike some other players in the field).
Once the new versions are released, the git mirroring will resume. This will immediately mirror all the individual commits, including detailed commit messages showing what the bugs were (and of course including the fix itself). And we are assigning public CVE numbers to all security related bugs. At this point, the commit messages held in the queue will also be released, and appear on the pgsql-committers list for anybody who wants to read up on them. And of course, complete tarballs with the full release will be made available alongside the binary packages.
Bottom line
It's a difficult balance between keeping things open so that everybody can verify what's going on, and keep exploit information out of the hands of the bad guys. Our goal with what we did this time is to minimize exposure to our users for a potentially very bad exploit (depends on the scenario for each individual install, of course), while we work with downstream distributions to make sure our fixes can reach the users as quickly as possible.
Is it the right way? We don't know. It's the first time we do this, and it's not something we plan to do as a general process. We'll of course have to evaluate whether it was successful once it's all done.
Finally, for those of you who are our users, a short repeat. A new release is planned next week, current schedule is release on April 4th. We advise all users to review the security announcement and apply the fix as quickly as possible if the vulnerability is targetable in your environment. The patch will require installation of new binaries and a restart of the database, but no further migration work than that.
We take the security of our users seriously, and try our best to protect them as much as possible. It's out belief that the tradoffs we've done here are in their best interest. The future will tell, of course, if that belief is correct.
Out with the old... PostgreSQL 8.3 reaches end-of-life.
As of todays release announcement, PostgreSQL 8.3 is no longer a supported version. PostgreSQL 8.3 is end of life in according with the 5-year support policy for all PostgreSQL major versions.
If you are running on any of the 8.3 versions, you should upgrade your system to 8.4 or newer immediately. If this cannot be done immediately, you should at least upgrade to 8.3.23 in the meantime. When upgrading, it's likely worth upgrading to 9.2 or at least 9.1, and not just to 8.4 which only has a bit over a year before it also goes end of life.
Any users of PostgreSQL 9.2, 9.1, 9.0 or 8.4 should still look at upgrading their systems to the latest minor release as of todays updates, since they contain both security and stability fixes. Minor version upgrades are, as always, just a matter of replacing your binaries and restarting the database. Automatic updates should also be out on the yum and apt repositories shortly.
PGConf.EU 2012 - what about next year
In our conference feedback, we also asked for a number of things that are designed to help us decide what to do next year. The most obvious one, of course, being where the conference should be next year.
Without even reading the texts behind the truncated texts, it's obvious that this didn't help us very much. The only city that scored higher than the average was Vienna - and it's likely not a coincidence that this is the option that's geographically closest to Prague, so it's the closest one for most of our attendees. In general we have to declare this as a draw - all suggested cities seem to be equally popular. So no direct guidance from there. While we have nothing to announce yet, we have already started considering locations for next year - but it won't be announced until we know something for certain.
PGConf.eu 2012 - evaluation and summary
It's been a bit longer than last time, but the time has come for a blog post that sums up the feedback we received for this years pgconf.eu in Prague. Let's start out with the overall impressions:
We've actually managed to improve the over all impression slightly - last year had 51% giving us a rating of 5, and this year we got 57%. Event more important, we've kept the rate of people who are giving a score of 3 or lower at less than 1%. According to the numbers, the programme quality was slightly worse than last year - down to 65% giving it a rating of 5, vs 71% last year. We still have 97% giving 4 or 5 - up from 95% last year (well within the margin of error).
All in all, I think we can safely say "job well done" to all the people who worked on the conference - thanks for all your efforts!