Date: Wed, 17 Feb 2016 09:27:50 +0100
From: Andres Freund <andres@anarazel.de>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: obartunov@gmail.com, Bruce Momjian <bruce@momjian.us>,
	"Joshua D. Drake" <jd@commandprompt.com>,
	Petr Jelinek <petr@2ndquadrant.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: pglogical - logical replication contrib module
Message-ID: <20160217082749.GI25464@awork2.anarazel.de>
References: <5685BB86.5010901@2ndquadrant.com>
 <56A84422.2030309@commandprompt.com>
 <20160216143820.GC31273@momjian.us>
 <CAF4Au4zmspWiqq=nCFF5Shy-3foaDiwNt+Xk2s7TLa-83D=9Hg@mail.gmail.com>
 <CAMsr+YHMDm0YjjZ63Z65mkHjv9hoRowO2PCozZXKT0cCQtVtZw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAMsr+YHMDm0YjjZ63Z65mkHjv9hoRowO2PCozZXKT0cCQtVtZw@mail.gmail.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2016-02-17 09:33:56 +0800, Craig Ringer wrote:
> Some DDL operations don't translate well to a series of replicatable
> actions. The case I hit the most is
> 
>    ALTER TABLE mytable ADD COLUMN somecolumn sometype NOT NULL DEFAULT
> some_function();
> 
> This is executed (simplified) by taking an ACCESS EXCLUSIVE lock, changing
> the catalogs but not making the changes visible yet, rewriting the table,
> and committing to make the rewritten table and the catalog changes visible.
> 
> That won't work well with logical replication.

FWIW, I think this is much less a fundamental, and more an
implementation issue. Falling back to just re-replicating the table, and
then optimizing a few common cases (only immutable DEFALUT/USING
involved) should be enough for a while.

Lets get the basics right, before reaching for the moon.

Greetings,

Andres Freund


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers