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.
