And I've just finish committing the last two patches in that series, for pg_recvlogical and documentation for the whole series of patches, so I'm feeling pretty fired up right now. (We don't ordinarily commit documentation separately from the main patch, but due to the size of this patch set, I made an exception.)
Just over three years ago, I wrote a blog post entitled The Case For Logical Replication. The truth of what I wrote in that blog post has not dimmed with time, and now we've got the beginnings of this functionality in PostgreSQL. I say "the beginnings" because logical replication can be thought of as two distinct features: (1) the ability to efficiently determine which tuples have been inserted, updated, or deleted and (2) the ability to apply those changes to a second copy of the data stored elsewhere. This patch set, as big and complicated as it is, addresses only the first of those needs - so that the second one will remain, for now, the province of tools outside the PostgreSQL core.
But even that is a big step forward. There are certainly ways of capturing tuple-level changes in existing releases of PostgreSQL, and there are a number of replication tools for PostgreSQL that do just that. Typically, that's done by writing the changes to user tables to a separate table which is managed by the replication system, and then reading the data from there to apply to other copies of the database. This new functionality, however, is more elegant and more performant than anything we have today. Even though much more work will be needed in order to deliver all the capabilities that users want, I think it's fair to say that we are on our way.
The official documentation build, all nice and pretty, is not up yet. But if you're in a rush, you can read the raw SGML here: