Horton

Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture

Kevin Grittner <kevin.grittner@wicourts.gov>

View thread
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Andres Freund" <andres@2ndquadrant.com>, "Robert Haas" <robertmhaas@gmail.com>
Cc: <pgsql-hackers@postgresql.org>
Date: 2012-06-19T21:36:47Z
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.

Andres Freund <andres@2ndquadrant.com> wrote:
 
> The problem is just that to support basically arbitrary decoding
> requirements you need to provide at least those pieces of
> information in a transactionally consistent manner:
> * the data
> * table names
> * column names
> * type information
> * replication configuration
 
I'm not sure that the last one needs to be in scope for the WAL
stream, but the others I definitely agree eventually need to be
available to a logical transaction stream consumer.  You lay out the
alternative ways to get all of this pretty clearly, and I don't know
what the best answer is; it seems likely that there is not one best
answer.  In the long run, more than one of those options might need
to be supported, to support different environments.
 
As an initial implementation, I'm leaning toward the position that
requiring a hot standby or a catalog-only proxy is acceptable.  I
think that should allow an application to be written which emits
everything except the replication configuration.  That will allow us
to hook up everything we need at our shop.
 
-Kevin