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 →
  1. Don't waste the last segment of each 4GB logical log file.

  2. Stamp HEAD as 9.3devel.

  3. Wake WALSender to reduce data loss at failover for async commit.

  4. Make the visibility map crash-safe.

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