Re: Restore replication settings when modifying a field type

From: Euler Taveira <euler(at)timbira(dot)com(dot)br>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: quanzongliang(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Restore replication settings when modifying a field type
Date: 2019-11-01 03:39:03
Message-ID: CAHE3wgh-JX+L_RBNQ-_SLjMNbXT4K6A5FpkLKsEmEO5mCgsUTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em seg, 28 de out de 2019 às 01:41, Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> escreveu:
>
> At Sat, 26 Oct 2019 16:50:48 +0800, Quan Zongliang <quanzongliang(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2019-11-01 03:42:43 Re: Allow CREATE OR REPLACE VIEW to rename the columns
Previous Message Fujii Masao 2019-11-01 03:00:31 Re: The command tag of "ALTER MATERIALIZED VIEW RENAME COLUMN"