Re: PostgreSQL 16 bug feedback

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: PostgreSQL 16 bug feedback
Дата
Msg-id CAKFQuwYTm+E9HLx3kVHjCked=xz3Ra-y4TTyrpOaNva-w6N3zQ@mail.gmail.com
обсуждение исходный текст
Ответ на PostgreSQL 16 bug feedback  ("yexiu-glory" <yexiu-glory@qq.com>)
Список pgsql-hackers

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


On Thursday, July 17, 2025, yexiu-glory <yexiu-glory@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.

В списке pgsql-hackers по дате отправления: