Re: [PATCH 16/16] current version of the design document
Merlin Moncure <mmoncure@gmail.com>
From: Merlin Moncure <mmoncure@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Date: 2012-06-13T14:21:12Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Don't waste the last segment of each 4GB logical log file.
- dfda6ebaec67 9.3.0 cited
-
Stamp HEAD as 9.3devel.
- bed88fceac04 9.3.0 cited
-
Wake WALSender to reduce data loss at failover for async commit.
- 2c8a4e9be273 9.2.0 cited
-
Make the visibility map crash-safe.
- 503c7305a1e3 9.2.0 cited
On Wed, Jun 13, 2012 at 6:28 AM, Andres Freund <andres@2ndquadrant.com> wrote: > +synchronized catalog at the decoding site. That adds some complexity to use > +cases like replicating into a different database or cross-version > +replication. For those it is relatively straight-forward to develop a proxy pg > +instance that only contains the catalog and does the transformation to textual > +changes. wow. Anyways, could you elaborate on a little on how this proxy instance concept would work? Let's take the case where I have N small-ish schema identical database shards that I want to aggregate into a single warehouse -- something that HS/SR currently can't do. There's a lot of ways to do that obviously but assuming the warehouse would have to have a unique schema, could it be done in your architecture? merlin