Re: Turning recovery.conf into GUCs - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Turning recovery.conf into GUCs
Date
Msg-id 5261A514.4060604@agliodbs.com
Whole thread Raw
In response to Turning recovery.conf into GUCs  (Jaime Casanova <jaime@2ndquadrant.com>)
Responses Re: Turning recovery.conf into GUCs  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 10/18/2013 01:35 PM, Andres Freund wrote:
> On 2013-10-18 13:16:52 -0700, Josh Berkus wrote:
>> I thought changeset extraction was the only thing going into core?  What
>> else do we need?
> 
> Well, I personally want more in core mid/long term, but anyway.

I've lost track of the plan, then.

Hmmm ... we need replication of DDL commands, no?

> Without released, proven and stable logical in-core replication
> technology using this, I don't see why repmgr or something related would
> need/want to change?

Repmgr is designed to manage binary replication, not perform it.

What will likely change first is Slony and Bucardo, who have a strong
interest in dumping triggers and queues.  A contrib module which did the
simplest implementation -- that is, whole-database M-S replication --
would also be a good idea, especially since it would provide an example
of how to build your own.

But I'd be wary of going beyond that in core, because you very quickly
get into the territory of trying to satisfy multiple exclusive
use-cases.  Let's focus on providing a really good API which enables
people to build their own tools.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: space reserved for WAL record does not match what was written: panic on windows
Next
From: Stephen Frost
Date:
Subject: Re: FDW API / flow charts for the docs?