Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Andres Freund <andres@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Alvaro Herrera <alvherre@2ndquadrant.com>, Simon Riggs <simon@2ndquadrant.com>
Date: 2012-10-15T18:19:54Z
Lists: pgsql-hackers
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 > > > > <hlinnakangas@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 I think Robert is right that if Slony can't use the API, it is unlikely any other replication system could use it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Move "hot" members of PGPROC into a separate PGXACT array.
- ed0b409d2234 9.2.0 cited