On Thursday, July 17, 2025, yexiu-glory <yexiu-gl...@qq.com> wrote:

>
>
> On Thursday, July 17, 2025, yexiu-glory <*yexiu-gl...@qq.com
> <yexiu-gl...@qq.com>*> wrote:
>
> I encountered a problem in PostgreSQL 16:
> In db1, there is a user table with fields id, name, phone, and createtime
> db2 replicates the user table from db1 through logical replication,
> specifying the fields as id, name, and createtime
> Then, in db1, perform the following operation: alter table user replica
> identity full;
> Then, modifying or deleting a record in the user table will result in an
> error,
> The error message for modification is as follows, and similar errors also
> occur when deleting.
> update "public"."user" set name='aaa’where id = 20005
> >ERROR: cannot update table "user"DETAIL: Column list used by the
> publication does not cover the replica identity.
>
>
> What did you expect to happen?
>
> I think it would be better if, when using the command "alter table user
> replica identity full" and specifying columns, the full-state
> synchronization should also synchronize all the specified fields?
>

Unless you are planning to write said patch this discussion seems quite
off-topic for -hackers at this time.  I have my qualms about the mechanics
of some of this but am fine with the fact your sequence of actions have
left the system unable to publish update or deletes on the channel and that
it requires user intervention to change that.

If you wish to continue pondering this I’d suggest you post a message to
the -general mailing list and include why it would be worth the effort to
do something different here.  Your toy example demonstrating behaviors
provides little insight as to why this is important.  And it most
definitely does not demonstrate a bug - the docs do cover this, though I
admit not in a way I find particularly easy to learn from.

David J.

Reply via email to