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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andres Freund" <andres(at)2ndquadrant(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture
Date: 2012-06-19 21:36:47
Message-ID: 4FE0AA9F0200002500048710@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-06-19 21:38:52 Re: performance regression in 9.2 when loading lots of small tables
Previous Message Peter Eisentraut 2012-06-19 21:35:26 Re: Testing 9.2 in ~production environment