понедельник, 29 мая 2017 г.

Back from PGCon 2017

          Last week my colleagues Alexander Korotlkov, Teodor Sigaev, Oleg Ivanov and I have been in Ottawa, Canada on the PGCon 2017 conference. Also Alexander Kukushkin (Zalando) has joined and spent a lot of time with us. I'm still having a jet lag (in my case second day is always the worst one) so I'm having some difficulties poetically describing how great it was, but I'll try.




Alexander (back), Teodor (right), Oleg (front) and I (left) in Ottawa.

          For me the most interesting part was to observe how open source community works offline (developer meeting, unconference, ...) and to meet PostgreSQL developers in person. Somehow it makes difference if you know that an email in pgsql-hackers@ was sent not by just someone whose name doesn't tell you a lot, but a real person you know, at least a little bit. Talks also were great. I personally most enjoyed Corruption War Stories by Christophe Pettus and So You Want To Make An Extension? by Keith Fiske.


PGCon 2017 Developer Meeting 2017 attendees. Photo by Dave Page. Source.

          I don't know for sure whose decision was to invite me on the developer meeting. Maybe it's just an imposter syndrome (probably not), but I'm not considering myself such a significant contributor to PostgreSQL. Anyway I would like to thank that person or persons whoever he is or they are. I hope I didn't disturb everyone too much ;)

          On the developer meeting and later on the unconference I tried to figure out whether it's possible to make PostgreSQL upgradable between major releases without a downtime. The reason why I'm so interested in this particular topic is that guys from Yandex told me that this is probably the biggest problem with PostgreSQL for them. Here you can find a detailed post by Vladimir Borodin on how they do an upgrade currently.

          There was reached a consensus that despite the fact that it could be done in theory the corresponding amount of work will be enormous, especially for a relatively small open source community. To solve this problem every newer version of PostgreSQL have to be backward compatible with catalog schema, tuples format, pages format and replication protocol of the previous version. This backward compatibility should be maintained and tested on every combination of platform, compiler and configuration flags supported by PostgreSQL. Concentrating on solving this problem with logical replication introduced in PostgreSQL 10 seems to be much more practical.

          Also I did a lightning talk "Data recovery using pg_filedump". Here are the slides:

          Unfortunately not many PostgreSQL users know about pg_filedump utility and that it's capable of restoring data in format suitable for using in COPY FROM queries (the feature I'm the one to blame for). TOAST is currently not supported but it should work for everything else including in-page compression. If you don't know the schema of the database you can restore it using pg_filedump as well. All this works even if PostgreSQL instance can't start and data is partially corrupted. I hope that you'll never need this knowledge, but according to Christophe's talk I mentioned above on rare occasions a tool like this can be helpful.

          And have you been on PGCon this year and if so what's your impression on the conference?

Source: Alexander Alekseev's blog
Mon 29 May 2017


Поделись этим