This question about pgloader usage coms in quite frequently, and I think the examples README goes a long way in answering it. It’s not exactly a tutorial but is almost there.
In case you’re wondering, here are the slides from the CHAR(11) talk I gave, about Skytools 3.0, soon to be released. That means as soon as I have enough time available to polish (or write) the documentation.
The slides for all the talks should eventually make their way to a central place, but expect some noticable delay here. Sorry about that, and have a good reading meanwhile!
CHAR(11) finished somewhen in the night leading to today, if you consider the social events to be part of it, which I definitely do. This conference has been a very good one, both on the organisation side of things and of course for its content.
It began with a perspective about the evolution of replication solutions, by Jan Wieck himself. In some way Skytools is an evolution of Slony, in the sense that it reuses the same concepts, a part of the design, and even share bits of the implementation (like the txid_snapshot datatype that were added in PostgreSQL 8.
We still have this problem to solve with extensions and their packaging. How to best organize things so that your extension is compatible with before 9.1 and 9.1 and following releases of PostgreSQL?
Well, I had to do it for the ip4r contribution, and I wanted the following to happen:
dpkg-deb: building package `postgresql-8.3-ip4r' ... dpkg-deb: building package `postgresql-8.4-ip4r' ... dpkg-deb: building package `postgresql-9.0-ip4r' ... dpkg-deb: building package `postgresql-9.1-ip4r' ... And here’s a simple enough way to achieve that.
While Magnus is all about PG Conf EU already, you have to realize we’re just landed back from PG Con in Ottawa. My next stop in the annual conferences is CHAR 11, the Clustering, High Availability and Replication conference in Cambridge, 11-12 July. Yes, on the old continent this time.
This year’s pgcon hot topics, for me, have been centered around a better grasp at SSI and DDL Triggers. Having those beasts in PostgreSQL would allow for auditing, finer privileges management and some more automated replication facilities.
