Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture
Date
Msg-id 4FE0AA9F0200002500048710@gw.wicourts.gov
Whole thread Raw
In response to Re: [RFC][PATCH] Logical Replication/BDR prototype and architecture  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Testing 9.2 in ~production environment
Next
From: Robert Haas
Date:
Subject: Re: performance regression in 9.2 when loading lots of small tables