Em seg, 28 de out de 2019 às 01:41, Kyotaro Horiguchi <horikyota....@gmail.com> escreveu: > > At Sat, 26 Oct 2019 16:50:48 +0800, Quan Zongliang <quanzongli...@gmail.com> > wrote in > > In fact, the replication property of the table has not been modified, > > and it is still 'i'(REPLICA_IDENTITY_INDEX). But the previously > > specified index property 'indisreplident' is set to false because of > > the rebuild. > > I suppose that the behavior is intended. Change of column types on the > publisher side can break the agreement on replica identity with > subscribers. Thus replica identity setting cannot be restored > unconditionally. For (somewhat artifitial :p) example: > I don't think so. The actual logical replication behavior is that DDL will always break replication. If you add a new column or drop a column, you will stop replication for that table while you don't execute the same DDL in the subscriber. What happens in the OP case is that a DDL is *silently* breaking the logical replication. IMHO it is a bug. If the behavior was intended it should clean pg_class.relreplident but it is not.
> Explicit setting of replica identity premises that they are sure that > the setting works correctly. Implicit rebuilding after a type change > can silently break it. > The current behavior forces the OP to execute 2 DDLs in the same transaction to ensure that it won't "loose" transactions for logical replication. > At least we need to guarantee that the restored replica identity > setting is truly compatible with all existing subscribers. I'm not > sure about potential subscribers.. > Why? Replication will break and to fix it you should apply the same DDL you apply in publisher. It is the right thing to do. [poking the code...] ATExecAlterColumnType records everything that depends on the column and for indexes it saves the definition (via pg_get_indexdef_string). Definition is not sufficient for reconstructing the replica identity information because there is not such keyword for replica identity in CREATE INDEX. The new index should call relation_mark_replica_identity to fix pg_index.indisreplident. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
