On 24 January 2013 01:17, Robert Haas <robertmh...@gmail.com> wrote: > I agree. The thing that scares me about the logical replication stuff > is not that it might be slow (and if your numbers are to be believed, > it isn't), but that I suspect it's riddled with bugs and possibly some > questionable design decisions. If we commit it and release it, then > we're going to be stuck maintaining it for a very, very long time. If > it turns out to have serious bugs that can't be fixed without a new > major release, it's going to be a serious black eye for the project. > > Of course, I have no evidence that that will happen.
This is a generic argument against applying any invasive patch. I agree 9.2 had major bugs on release, though that was because of the invasive nature of some of the changes, even in seemingly minor patches. The most invasive and therefore risky changes in this release are already committed - changes to the way WAL reading and timelines work. If we don't apply a single additional patch in this CF, we will still in my opinion have a major requirement for beta testing prior to release. The code executed here is isolated to users of the new feature and is therefore low risk to non-users. Of course there will be bugs. Everybody understands what new feature means and we as a project aren't exposed to risks from this. New feature also means groundbreaking new capabilities, so the balance of high reward, low risk means this gets my vote to apply. I'm just about to spend some days giving a final review on it to confirm/refute that opinion in technical detail. Code using these features is available and marked them clearly as full copyright transfer to PGDG, TPL licenced. That code is external not by author's choice, but at the specific request of the project to make it thay way. I personally will be looking to add code to core over time. It was useful for everybody that replication solutions started out of core, but replication is now a core requirement for databases and we must fully deliver on that thought. I agree with your concern re: checksums and foreign key locks. FK locks has had considerable review and support, so I expect that to be a manageable issue. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers