Re: [RFC][PATCH] wal decoding, attempt #2 - Design Documents (really attached)
Christopher Browne <cbbrowne@gmail.com>
From: Christopher Browne <cbbrowne@gmail.com>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-10-15T20:08:28Z
Lists: pgsql-hackers
On Mon, Oct 15, 2012 at 3:18 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > On 15 October 2012 19:19, Bruce Momjian <bruce@momjian.us> wrote: >> I think Robert is right that if Slony can't use the API, it is unlikely >> any other replication system could use it. > > I don't accept that. Clearly there is a circular dependency, and > someone has to go first - why should the Slony guys invest in adopting > this technology if it is going to necessitate using a forked Postgres > with an uncertain future? That would be (with respect to the Slony > guys) a commercial risk that is fairly heavily concentrated with > Afilias. Yep, there's something a bit too circular there. I'd also not be keen on reimplementing the "Slony integration" over and over if it turns out that the API churns for a while before stabilizing. That shouldn't be misread as "I expect horrible amounts of churn", just that *any* churn comes at a cost. And if anything unfortunate happens, that can easily multiply into a multiplicity of painfulness(es?). -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
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