On 17 February 2016 at 16:27, Andres Freund <and...@anarazel.de> wrote:
> 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 Do you mean taking a new schema dump from the upstream? Or just the table data? We already receive the table data in a pg_temp_<nnnn> virtual relation. While it'd be nice to have a better way to map that to the relation being rewritten without having to do string compares on table names all the time, it works. If we do a low level truncate on the table *then* execute the DDL on the empty table and finally rewrite it based on that stream as we receive it that should work OK. > Lets get the basics right, before reaching for the moon. > Yeah, it's got to be incremental. Though I do think we'll need to address DDL affecting shared catalogs. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
