On Monday, October 15, 2012 08:19:54 PM Bruce Momjian wrote: > On Mon, Oct 15, 2012 at 09:57:19AM +0200, Andres Freund wrote: > > On Monday, October 15, 2012 04:54:20 AM Robert Haas wrote: > > > On Thu, Oct 11, 2012 at 3:15 AM, Heikki Linnakangas > > > > > > <hlinnakan...@vmware.com> wrote: > > > > IMHO that's a good thing, and I'd hope this new logical replication > > > > to live outside core as well, as much as possible. But whether or > > > > not something is in core is just a political decision, not a reason > > > > to implement something new. > > > > > > > > If the only meaningful advantage is reducing the amount of WAL > > > > written, I can't help thinking that we should just try to address > > > > that in the existing solutions, even if it seems "easy to solve at a > > > > first glance, but a solution not using a normal transactional table > > > > for its log/queue has to solve a lot of problems", as the document > > > > says. Sorry to be a naysayer, but I'm pretty scared of all the new > > > > code and complexity these patches bring into core. > > > > > > I do not personally believe that a WAL decoding solution adequate to > > > drive logical replication can live outside of core, at least not > > > unless core exposes a whole lot more interface than we do now, and > > > probably not even then. Even if it could, I don't see the case for > > > making every replication solution reinvent that wheel. It's a big > > > wheel to be reinventing, and everyone needs pretty much the same > > > thing. > > > > Unsurprisingly I aggree. > > > > > That having been said, I have to agree that the people working on this > > > project seem to be wearing rose-colored glasses when it comes to the > > > difficulty of implementing a full-fledged solution in core. > > > > That very well might be true. Sometimes rose-colored glasses can be quite > > productive in getting something started... > > > > Note at this point were only want wal decoding, background workers and > > related things to get integrated... > > Well, TODO does have: > > Move pgfoundry's xlogdump to /contrib and have it rely more closely on > the WAL backend code
Uhm. How does that relate to my statement? The xlogreader code I submitted does contain a very small POC xlogdump with almost no code duplication. It needs some work to be really useful though. > I think Robert is right that if Slony can't use the API, it is unlikely > any other replication system could use it. I aggree and I don't think I have ever said something contrary. I just don't want to be the only one working on slony integration. I am ready to do a good part of that, but somebody with slony experience needs to help, especially on consuming those changes. Greetings, Andres -- Andres Freund 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
